principe d'invariance -boxing dans une collection

Citation:
Envoyé par new_wave
Principe d'invariance:

Ce principe s'applique-t-il uniquement s'il existe un lien d'héritage entre deux types A et B?
Ex:
Code:

1 2 3 Wrapper<string>stringWrapper; IWrapper<Object> storedObjectWrapper= stringWrapper;
Dans ce cas, l'interface IWrapper<T> est invariante et l'instruction IWrapper<Object> storedObjectWrapper= stringWrapper;
renverra une erreur à l'execution.

Or est-ce du fait que le type string est un sous type de Object ou, si j'avais ecrit
Code:

1 2 IWrapper<int> storedObjectWrapper= stringWrapper;
cette instruction n'aurait pas pu s'exécuter de toute manière.
Pour qu'un IWrapper<B> puisse être affecté à un IWrapper<A>, il faut
- que l'interface IWrapper<T> soit covariante
- qu'il existe une conversion de référence de B vers A (autrement dit, que B hérite de A)

ou alors :

- que l'interface IWrapper<T> soit contravariante
- qu'il existe une conversion de référence de A vers B (autrement dit, que A hérite de B)

Si IWrapper<T> est invariante (ni covariante, ni contravariante), tu ne pourras jamais affecter un IWrapper<B> à un IWrapper<A> (à moins que A et B soient le même type...)

D'autre part, cela ne fonctionne qu'avec les types référence ; si A ou B est un type valeur, il n'y a pas de "conversion de référence" possible entre les 2, et donc pas de variance. Donc dans ton 2e exemple, même si l'interface n'était pas invariante, ce ne serait pas possible.

Citation:

Envoyé par new_wave

Pouvez-vous m'expliquer pourquoi la restriction liée à l'invariance s'applique aux types génériques et non pas aux types non génériques?

Si tu poses cette question, c'est que tu n'as vraiment pas compris ce qu'est la variance... La variance (en C# du moins) n'a de sens que pour des types génériques, de par sa définition. Regarde cet article pour plus d'infos sur le sujet : Variance en C# 4.0

Citation:

Envoyé par new_wave

Ensuite, du fait qu'un type est générique, il contient , pour toutes les instances de ce type, les mêmes méthodes(que ce soit dans le cas où le type générique est remplace par le type Object ou qu'il soit remplacé par le type int) .

Je ne comprends pas ta phrase. Ca n'a rien à voir avec le fait que le type soit générique, c'est vrai pour n'importe quel type.

Citation:

Envoyé par new_wave

Pourquoi donc empêcher une telle instruction

Code:

IWrapper<Object> storedObjectWrapper= stringWrapper;

A cause de cette histoire de variance. Il ne suffit pas que String hérite de Object, il faut aussi que IWrapper<T> soit covariante.

Prenons un exemple plus concret, avec l'interface IList<T>. Le morceau de code suivant n'est pas légal, mais supposons qu'il le soit et observons les conséquences :
Code:

1 2 3 4 5 IList<string> stringList = new List<string>(); IList<object> objectList = stringList; objectList.Add("hello world"); // OK, on peut ajouter une chaine à une List<string> objectList.Add(new Toto()); // Oups !
Du point de vue du compilateur, la dernière ligne est parfaitement légale, puisque Toto (comme tous les autres types) hérite de object, donc on peut ajouter un Toto à une IList<object>, non ? Sauf qu'en réalité, la liste est toujours une instance de List<string>, qui ne peut contenir que des strings ! Donc si ce morceau de code était légal, il causerait une erreur à l'exécution...

C'est pour ça que IList<T> n'est pas covariante : si elle l'était, cela permettrait des erreurs de typage que le compilateur ne pourrait pas détecter.

Pour ton IWrapper<T>, tout dépend de ce qu'il fait : si le type T apparait seulement "en sortie" (par exemple comme valeur de retour d'une propriété ou d'une méthode), alors on peut déclarer IWrapper<T> comme étant covariante en T : interface IWrapper<out T>. Mais si ce n'est pas le cas, rien ne dit que la conversion de IWrapper<string> en IWrapper<object> soit sûre, donc elle est considérée comme illégale.

Citation:

Envoyé par new_wave

Pourquoi donc empêcher une telle instruction

Code:

IWrapper<Object> storedObjectWrapper= stringWrapper;

Pas nécessairement. Si c'est une List<int> par exemple, il n'y a pas de boxing. Mais si c'est une collection non typée comme ArrayList, ou une collection générique comme List<object>, les valeurs seront effectivement boxées.

Citation:

Envoyé par new_wave

opérateurs de conversion: sont ils simplement tous ceux qui permettent de caster dans un type défini:(int), (string) etc...?

Oui, le boxing concerne uniquement les types valeurs. Il se produit quand tu passes une instance d'un type valeur à un endroit où un type référence est attendu (par exemple object, ou une interface)

Citation:

Envoyé par new_wave

Que signifie qu'un opérateur est non polymorphe.

Le délégué pointe toujours vers une méthode ; il est "immuable" (immutable en anglais), donc une fois créé, il ne change plus. Donc pour reprendre ta phrase de façon plus exacte :
Code:

1 2 3 4 5 IList<string> stringList = new List<string>(); IList<object> objectList = stringList; objectList.Add("hello world"); // OK, on peut ajouter une chaine à une List<string> objectList.Add(new Toto()); // Oups !
(à strictement parler, elle restera en mémoire jusqu'à ce que le GC soit passer par là bien sûr...)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 void Main() { var f1 = new Foo(null); var f2 = new Foo(string.Empty); var f3 = new Foo("hello world"); if (f1) Console.WriteLine ("f1: true"); else Console.WriteLine ("f1: false"); if (f2) Console.WriteLine ("f2: true"); else Console.WriteLine ("f2: false"); if (f3) Console.WriteLine ("f3: true"); else Console.WriteLine ("f3: false"); } class Foo { private readonly string _value; public Foo(string value) { _value = value; } public string Value { get { return _value; } } public static bool operator true(Foo foo) { return !string.IsNullOrEmpty(foo.Value); } public static bool operator false(Foo foo) { return string.IsNullOrEmpty(foo.Value); } }
Oui. Sauf que l'opérateur unaire "+" ne sert à rien, il est implicite. Que tu écrives 42 ou +42, ça revient au même.

Ca indique si un objet doit être considéré comme true ou false dans une condition. Par exemple, on peut créer une classe Foo qui est considérée comme true si ça valeur n'est pas nulle ou vide :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 void Main() { var f1 = new Foo(null); var f2 = new Foo(string.Empty); var f3 = new Foo("hello world"); if (f1) Console.WriteLine ("f1: true"); else Console.WriteLine ("f1: false"); if (f2) Console.WriteLine ("f2: true"); else Console.WriteLine ("f2: false"); if (f3) Console.WriteLine ("f3: true"); else Console.WriteLine ("f3: false"); } class Foo { private readonly string _value; public Foo(string value) { _value = value; } public string Value { get { return _value; } } public static bool operator true(Foo foo) { return !string.IsNullOrEmpty(foo.Value); } public static bool operator false(Foo foo) { return string.IsNullOrEmpty(foo.Value); } }
En pratique ça ne sert pas beaucoup...

Citation:

Envoyé par new_wave

opérateurs de conversion: sont ils simplement tous ceux qui permettent de caster dans un type défini:(int), (string) etc...?

Ce sont tout simplement les opérateurs qui permettent de convertir un type vers un autre. Cas particulier : certaines conversions entre les types primitifs (int, double, etc) sont définis au niveau du langage lui-même, et non par un opérateur dans le code.

Citation:

Envoyé par new_wave

Que signifie qu'un opérateur est non polymorphe.

Que le polymorphisme ne s'applique pas. Ce qui est logique d'ailleurs, puisque les opérateurs sont définis comme des méthodes statiques, et que le polymorphisme n'a de sens que pour des méthodes d'instance...