Typed Collection et Heritance

Version imprimable

Bonjour
Si il y a des fous , qui se transforme en compilateur, je ne comprend pas pourquoi j'ai un implicite cast

J'ai les classes suivante
Code:

1 2 public class ClientPresenter : MyBasePresenter<ClientModel, IClientView>
Code:

1 2 3 4 public MyBasePresenter<TModel, TView> : Architechture.BasePresenter<TModel, TView> where TModel: MyBaseModel, new() where TView : Architechture.IBaseView
Code:

1 2 public class ClientModel : myBaseModel
Code:

public interface IClientView : Architechture.IBaseView

Quand je fais
Code:

1 2 3 4 ClientPresenter clientPresenter; myBasePresenter<MyBaseModel, Architechture.IBaseView> basePresenter; basePresenter = clientPresenter;
J'ai un implicite cast et je ne vois pas pourquoi

Merci

sinon avec un truc plus simple peut-être

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
    public interface IMyI
    {
    }
 
    class a : IMyI
    {
    }
 
   class myList : List<a>   {  }
 
 
    class Program
    {
        static void Main(string[] args)
        {
            List<IMyI> t;
            myList mylist;
            mylist = new myList();
            t = mylist;
 
        }
    }

Logiquement t ne devrais pas pouvoir avoir un myList?

02/08/2011, 14h00
Nathanael Marchand

Vivivi, c'est ce qu'on appelle la covariance.
On peut prendre l'exemple avec les List<T>:
Même si String est un object, List<String> n'est pas une List<object>.
Depuis .Net 4, c'est un peu plus fin, car la phrase au dessus reste vrai pour List<T> mais pour IEnumerable<T> on a le droit de dire que IEnumerable<String> est un IEnumerable<object>

http://msdn.microsoft.com/en-us/library/dd233059.aspx

Pour résumer, ton ClientPresenter qui est un MyBasePresenter<ClientModel, IClientView> n'est pas un MyBasePresenter<MyBaseModel, Architechture.IBaseView>
02/08/2011, 14h10
BenoitM

Donc je dois passer en .Net 4 pour avoir une chance que ca marche? :)
02/08/2011, 14h15
BenoitM
Oki et en plus du .Net 4 il faut faire le casting explicitement
Code:

1 2 3 4 List<IMyI> t; myList mylist; mylist = new myList(); t = mylist.ToList<IMyI>();
Moins intelligent que je ne le pensais la covariance ;)
02/08/2011, 14h18
brachior

C'est malheureusement mon plus gros problème en C# (surement en .NET d'ailleurs Oo)
J'utilise le Framework 4 et pourtant j'ai du rusé en passant par une interface de marquage Oo
(merci tomlev ^^)
Je pense pas que tu doives en arriver jusque là mais je ne sais pas si il y a possibilité de le faire sans le voir comme un object (C# garde en mémoire le type malgré ça ^^)
02/08/2011, 14h58
BenoitM
Tiens je me pose une question quels sont les coûts du casting de
Code:

1 2 3 4 IMyI myinterface=myA ; et List<IMyI> myList= mylist.ToList<IMyI>();
Je suppose que la covariance est extrèmement coûteuse au niveau ressource
Vu comme c'est implémenté ca ressemble plus à la création d'un nouvel objet qu'à un casting
02/08/2011, 15h05
tomlev

Citation:

Envoyé par BenoitM

Je suppose que la covariance est extrèmement coûteuse au niveau ressource

Non, la covariance c'est gratuit au niveau resources... c'est juste une astuce au niveau du compilateur. Mais ce que tu fais, c'est pas vraiment de la covariance (enfin tu exploites juste le fait qu'un IEnumerable<a> puisse être utilisé là où un IEnumerable<IMyI> est attendu)

Citation:

Envoyé par BenoitM

Vu comme c'est implémenté ca ressemble plus à la création d'un nouvel objet qu'à un casting

Avec le code que tu utilises, effectivement ça crée une nouvelle liste. Ca n'a rien à voir avec la covariance, c'est la méthode ToList qui fait ça.
02/08/2011, 15h23
BenoitM

Sans le toList ca marchait pas.

Je vais rééssayé un exemple plus propre .

La c'est parce que List est la "seule" classe typé que j'avais sous la main
02/08/2011, 15h33
tomlev
Non mais justement, avec une List<T> la covariance ne marche pas.

- d'une part parce que ça ne marche que pour les interfaces et delegates, pas les classes concrètes.

- d'autre part parce que le type T se trouve en entrée ET en sortie de la classe, et que donc la covariance (tout comme la contravariance) ne pourrait pas s'appliquer ici sans casser la sécurité des types. En effet, si tu pouvais appliquer la covariance à List<T>, ça permettrait de faire ça :
Code:

1 2 List<object> list = new List<string>(); list.Add(42);
Ca compilerait sans problème, mais ça pèterait à l'exécution parce que tu essaies d'ajouter un int à une liste de string

Soit dit en passant, une certaine forme de covariance est possible pour les tableaux, mais c'est considéré aujourd'hui comme un défaut de conception. Ce code compile, mais lève une exception :
Code:

1 2 object[] array = new string[2]; array[0] = 42; // ArrayTypeMismatchException

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
 public class VehiculeAMoteur<Mot>
    where Mot:Moteur {  }
 
    public class Moteur
    {
    }
 
    public class Train<MoteurElectrique> : VehiculeAMoteur<Moteur>
    {
    }
 
    public class MoteurElectrique : Moteur { }
 
    class Program
    {
        static void Main(string[] args)
        {
            VehiculeAMoteur<Moteur> vehiculeAMot;
            Train<MoteurElectrique> Train=new Train<MoteurElectrique>();
            vehiculeAMot = Train;            
        }
    }

Ici il me semble que je fais la même chose que ce que je voulais faire au début
Et ca marche même en .Net 3.5

Je vais réssayer mes classes d'origines pour voir si j'ai pas loupé un truc

02/08/2011, 15h59
BenoitM
Autre question quelle est la différence entre
Code:

1 2 3 public class VehiculeAMoteur<Mot> where Mot:Moteur { }
et

Citation:

public class VehiculeAMoteur<Moteur>
02/08/2011, 16h11
tomlev
Citation:

Envoyé par BenoitM

Ici il me semble que je fais la même chose que ce que je voulais faire au début

Bah oui mais dans ton exemple Train<MoteurElectrique> hérite de VehiculeAMoteur<Moteur>, donc c'est normal que ça marche... Dans ce que tu as écrit, il n'y a aucun lien entre MoteurElectrique (le paramètre de type, pas la classe) et Moteur
(soit dit en passant, le fait d'utiliser le même nom pour une classe et pour un paramètre de type générique ne facilite pas la compréhension...)

Tu ne pourrais pas affecter, par exemple, un VehiculeAMoteur<MoteurAExplosion> à un VehiculeAMoteur<Moteur>, même si MoteurAExplosion hérite de Moteur
Citation:
Envoyé par BenoitM

Autre question quelle est la différence entre

Code:

1 2 3 public class VehiculeAMoteur<Mot> where Mot:Moteur { }

et

Code:

public class VehiculeAMoteur<Moteur>
Dans la 2eme déclaration, Moteur est un paramètre de type, ce n'est pas la classe Moteur. D'où ma remarque précédente... normalement pour les paramètres de type on préfixe le nom par T pour éviter ce genre de confusion :
Code:

1 2 3 4 public class VehiculeAMoteur<TMoteur> where TMoteur : Moteur { }

De l'exterieur: aucune!
De l'interieur: plein de chose!

Code:

1
2
3
4
5
6
7
8
 
public class Moteur
{
    public void Avancer()
    {
        //Vroum
    }
}

Code:

1
2
3
4
5
6
7
8
9
 
public class VehiculeAMoteur<TMoteur>
{
    public TMoteur MonMoteur {get;set;}
    public void Avancer()
    {
        // MonMoteur est ici un object, on ne peut pas acceder à MonMoteur.Avancer()
    }
}

Code:

1
2
3
4
5
6
7
8
9
10
 
public class VehiculeAMoteur<TMoteur>
    where TMoteur : Moteur
{
    public TMoteur MonMoteur {get;set;}
    public void Avancer()
    {
        MonMoteur.Avancer(); //Avec la contrainte on sait que MonMoteur est un Moteur
    }
}

02/08/2011, 16h43
BenoitM

Merci :)

Avec un petit test c'est plus facile pour comprendre ;)