Discussion :

[brachior]

Bonjour,

C'est la première fois que je poste sur ce forum.
Mais ce dernier m'a toujours aidé ^^
(j'espère cette fois encore ^^)

Niveau programmation objet fortement typé, j'utilise Java.
Pour un projet je dois utiliser C# (framework 4.0 ^^).
Je sais que les deux ne sont pas très différents mais quand même ^^
(J'ai lu la quasi totalité de la spec ^^')

Je ne lancerai pas de Troll ^^,
les deux ont leurs faiblesses et leurs avantages ^^

Voila mon problème,
J'ai un objet paramétrable (ou générique en C#)
Appelons le «Obj<T>»

J'aimerai stocker plusieurs instances de «Obj»
mais avec des paramètres différents (String, Double, ...)

En Java je sais faire,
En C#, ..., là je bloque =/
Les types paramétrés ne sont pas gérés de la même manière,
Et donc C# ne dispose pas de la «Wildcard» de Java («?»)

Voila en Java ce que ça donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
public class Obj<T> {
 
	T obj = null;
 
	public Obj(T obj) {
		super();
		this.obj = obj;
	}
 
	public T method() {
		return obj;
	}
 
	public static void main(String[] args) {
		Obj<Double> o1 = new Obj<Double>((double) 25.2);
		Obj<String> o2 = new Obj<String>("coucou");
 
		List<Obj<?>> list = new ArrayList<Obj<?>>();
		list.add(o1);
		list.add(o2);
 
		for (Obj<?> obj : list) {
			System.out.println(obj.method());
		}
	}
}

En C#,
J'ai seulement réussi à les stocker en temps qu'Object.
Il ne perd pas les types,
Mais je dois obligatoirement coder en dur le cast avec le bon type
(pas possible en générique)
Et puis bon, se trimballer avec des Object,
Ça perd tout le charme des templates Oo

Voila, si quelqu'un à une solution je suis preneur ^^
Je ne reste pas bloqué sur un stockage par liste,
Si il y a un autre moyen je testerai volontier.

Merci.

[tomlev]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<Obj<?>>

Il n'y a pas d'équivalent à ça en C#. C'est lié à la façon dont les génériques sont implémentés : en Java, la VM n'a aucune connaissance des génériques, c'est juste une astuce du compilateur qui introduit automatiquement des cast là où c'est nécessaire. Alors qu'en C#, le CLR (la VM si tu préfères) gère nativement les génériques, aucun cast n'est effectué : le runtime crée réellement un nouveau type pour chaque paramètre de type que tu utilises (i.e. Obj<int> et Obj<string> seront vraiment 2 types différents, alors qu'en Java ce serait en fait le même type), et ces types n'ont pas de relation entre eux (ils n'héritent pas d'une classe de base commune par exemple)

Ça perd tout le charme des templates Oo

Les génériques ressemblent aux templates, mais c'est un mécanisme différent...


Pour régler ton problème, voilà ce que je te suggère :

- crée une interface non générique (par exemple IObj), dans laquelle tu définis la méthode "method" avec un type de retour "object"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface IObj
{
    object method();
}

- dans ta classe Obj<T>, implémente cette interface explicitement. Cela te permet notamment de déclarer également une méthode "method" avec le type de retour que tu veux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Obj<T> : IObj
{
 
        ...
 
	public T method()
        {
		return obj;
	}
 
        // Implémentation explicite
        object IObj.method()
        {
            return this.method();
        }
 
        ...
}

- A la place de List<Obj<?>>, utilise List<IObj> :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
	public static void Main(string[] args)
        {
		Obj<double> o1 = new Obj<double>(25.2);
		Obj<string> o2 = new Obj<string>("coucou");
 
		IList<IObj> list = new List<IObj>();
		list.Add(o1);
		list.Add(o2);
 
		foreach (IObj obj in list)
                {
			Console.WriteLine(obj.method());
		}
        }

[brachior]

Génial Oo

Je me disais bien aussi que c'était faisable en C# aussi ^^
C'est un peu détourné mais ça fonctionne (c'est le principal ^^)

Pour ce qui est de l'implémentation des génériques,
Oui oui j'ai bien lu tout ça ^^

Et bien je te remercie ^^
Et c'est encore une fois une victoire grâce à vous ^^

[brachior]

Hum, en fait si je fais comme ça,
Je perd le typage dans ma classe =/

Je m'explique,

Dans ma classe Obj<T>,
J'ai une liste d'un autre objet typé, appelons le AObj<T>.

Cette liste à un type fixe qui est spécifié par Obj.
Si j'utilise une interface qui de-spécialise ma classe Obj,
je perds aussi le type de ma liste.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
public class AObj<T>
{
  ...
}
 
public interface IObj
{
  IList<AObj<object>> Buffers { get; }
  object method();
}
 
public class Obj<T> : IObj
{
  public IList<AObj<T>> Buffers { get; private set; }
  public T method()
  {
    ...
  }
 
  IList<AObj<object>> IObj.Buffers
  {
    // ça il ne veut pas, et avec un cast ça plante =/
    get { return this.Buffers; }
  }
  object IObj.method()
  {
    return this.method();
  }
}

J'ai essayé de refaire une autre interface IAObj mais,
D'une ça poserait problème du fait que la liste pourrai contenir différents types
Et d'autre part, bah ça fonctionne pas xD (enfin je l'ai peut être mal fait Oo)

Bon voila ^^
Je suis re bloqué quasi au même point =/

Merci de votre aide

[brachior]

Bonjour,

Je relance mon problème en quête de réponses ^^
J'en profite pour remettre à plat mon problème

J'ai un objet Box Module, qui contient un nombre indéterminé d'objets Input et Output.
Ces deux derniers héritent d'un objet IO qui lui contient un nombre indéterminé d'objets Buffer.
Ce dernier possède une liste d'objet Bloc qui lui est typé.


Voila en gros le diagramme ^^

Donc tout le monde est typé sauf Module
Et Module peut contenir des Input et des Output de type différents.

Avec la méthode précédente, je me retrouve avec l'obligation d'avoir des Buffer de Bloc d'Object =/

Merci de votre aide ^^

[DonQuiche]

Avant tout je présume qu'un IO<Int32> ne se réfère qu'à des Buffer<Int32>, qui lui-même ne contient que des Bloc<Int32>, n'est-ce pas ? Et donc seul Module mélange des génériques avec des arguments différents.

Dans ce cas, c'est simple : liste toutes les fonctions et propriétés consommées par Module et place-les dans une ou plusieurs interfaces non-génériques. Et pour reprendre ta question précédente, ton IObj.Buffers aurait dû renvoyer un IList<IObj>. Songe à l'implémentation explicite des interfaces si tu veux conserver une propriété Buffer générique tout en implémentant une version non-générique pour l'interface. Et facilite-toi la vie avec la covariance des génériques (un IList<Obj<Int32>> peut être implicitement casté en un IList<IObj>)

[brachior]

Avant tout je présume qu'un IO<Int32> ne se réfère qu'à des Buffer<Int32>, qui lui-même ne contient que des Bloc<Int32>, n'est-ce pas ? Et donc seul Module mélange des génériques avec des arguments différents.

C'est bien ça ^^
Et merci pour ta réponse ^^

Par contre Module n'a pas vraiment de problème,
La méthode proposée par tomlev fonctionne à peu près.
Module ne devant se soucier que du stockage des Input et Output.
Il n'y a pas d'accès typé nécessaire depuis Module vers les IO.

La où la méthode précédente bloque,
C'est qu'étant donné que (par exemple) Input implémente une interface non générique IInput,
Input se voit obligé de créer des Buffer de type object =/

Je laisse un peu de code pour voir ^^

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
    public class Bloc<TData>
    {
        public TData[] Datas { get; set; }
    }
 
    public class Buffer<TData> : IBuffer
    {
        public IList<Bloc<TData>> Blocs { get; set; }
    }
 
    public class IO<TData>
    {
        public IList<Buffer<TData>> Buffers { get; set; }
    }
 
    public class IInput : IO<object>
    {
    }
 
    public class Input<TData> : IInput
    {
        public Input()
        {
            Buffers.Add(new Buffer<object>()); // OK
            Buffers.Add(new Buffer<int>()); // marche pas
            Buffers.Add(new Buffer<string>()); // marche pas
        }
    }
 
    public class Module
    {
        public IList<IInput> Inputs { get; set; }
        public IList<IOutput> Outputs { get; set; }
 
        public Module()
        {
            Inputs = new List<IInput>();
            Inputs.Add(new Input<string>());
            Inputs.Add(new Input<int>());
        }
    }

[tomlev]

Bah il faut utiliser le même principe que précédemment : une interface IBuffer non générique, implémentée par Buffer<TData>...

[brachior]

Hum, Si on met de côté le problème de la liste qui n'est plus typée proprement.
(c'est à dire que mon IO peut avoir des Buffer de types différents =/)
J'aurai donc un truc comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
    public interface IBuffer
    {
        void addDatas(object[] datas);
    }
 
    public class Buffer<TData> : IBuffer
    {
        public IList<Bloc<TData>> Datas { get; set; }
 
        public Buffer()
        {
            Datas = new List<Bloc<TData>>();
        }
 
        public void addDatas(TData[] datas)
        {
            Datas.Add(new Bloc<TData>(datas));
        }
 
        void IBuffer.addDatas(object[] datas)
        {
            this.addDatas(datas); // ne veut pas
        }
    }

Mais là ça passe pas, surement dû au tableau =/
(il ne veut pas caster en TData[] =/)
Il me demande une méthode private void addDatas(object[] datas)
Pourtant le type de datas est bien le bon =/

Ah et juste pour dire ^^
Je me suis trompé en écrivant le code de mon post précédent =/

Je recopie juste ce qui n'est pas bon ^^

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
    public class Input<TData> : IInput
    {
        public Input()
        {
            Buffers.Add(new Buffer<TData>());
        }
    }
 
    class Program
    {
        static void Main(string[] args)
        {
            Module m1 = new M1();
            m1.Inputs[0].Buffers[0].addDatas(new string[] { "plip", "plap", "plop" });
            Console.ReadLine();
        }
    }

[brachior]

Bon le seul moyen que j'ai trouvé,
C'est de recopier le tableau ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
    void IBuffer.addDatas(object[] datas)
    {
        TData[] d = new TData[datas.Length];
        for (int i = 0; i < datas.Length; i++)
        {
            d[i] = (TData) datas[i];
        }
        this.addDatas(d);
    }

Je ne considère pas mon problème comme résolu
Puisque bon, recopier un tableau en le castant ...
Je ne pense pas qu'on puisse faire plus moche =/

[tomlev]

Comme ça, ça doit passer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        void IBuffer.addDatas(object[] datas)
        {
            this.addDatas((TData[])datas);
        }

[brachior]

Non malheureusement =/

J'ai l'erreur comme quoi il ne peut pas convertir =/

De plus ma méthode "à l'arrache" (qui bouffe des ressources) ne fonctionne pas avec les nombres (int, double, ...).
Je trouve ça d'ailleurs étonnant pour un langage qui se dit "tout objet" Oo
Bon après j'ai peut être pas bien cerné le principe de "tout objet" ^^

[tomlev]

Non malheureusement =/

J'ai l'erreur comme quoi il ne peut pas convertir =/

Ah oui, effectivement... tu peux faire ça, mais c'est un peu moche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
        void IBuffer.addDatas(object[] datas)
        {
            this.addDatas((TData[])(object)datas);
        }

De plus ma méthode "à l'arrache" (qui bouffe des ressources) ne fonctionne pas avec les nombres (int, double, ...).
Je trouve ça d'ailleurs étonnant pour un langage qui se dit "tout objet" Oo
Bon après j'ai peut être pas bien cerné le principe de "tout objet" ^^

Comment ça "ne marche pas" ?
C'est probablement lié au fait que les nombres (int, double, etc) sont des types valeur et non des types référence. Quand tu les manipules via une variable de type object, il y a un boxing qui est fait, ce qui explique peut-être les problèmes que tu rencontres

[Bluedeep]

Comment ça "ne marche pas" ?
C'est probablement lié au fait que les nombres (int, double, etc) sont des types valeur et non des types référence. Quand tu les manipules via une variable de type object, il y a un boxing qui est fait, ce qui explique peut-être les problèmes que tu rencontres

La précision est utile car ce concept n'existe pas en Java, qui impose des passer par des types spécifiques encapsulant les types intrinsèques.

[brachior]

Hum ... Pas bête ^^
Je me suis focalisé sur la notion de tableau Oo
J'ai l'impression que .NET est capricieux avec ça ^^

Mais un tableau est un object ...
Donc passer un object[] ou un object,
Ça revient au même (à part pour la lisibilité Oo)

Qui plus est, en demandant un simple object,
Je peux passer un tableau d'entier Oo

Bon je pense prendre cette option avec un petit commentaire dans la doc xD
Je vais regarder du côté de la programmation par contrat pour solidifier tout ça ^^

Oui c'est vrai qu'il y a type valeur et type référence en C#
J'ai quand même l'impression que c'est une bidouille pour ne pas dire type primitif ^^
( bon oui y a les struct qui sont aussi des types valeur
Mais quand même ...
Je trouve ça fourbe de la part de C# =P )

Quel concept ? L'auto-boxing ? Si c'est ça, il existe en Java Oo

Si c'est les différences de type,
Java le comprends en tant que type primitif pour les valeurs,
Il ne possède pas d'équivalence aux struct
(de ce que je sache ^^ je demanderai à mon prof ^^)

Enfin voila ...
Un grand merci pour votre aide ^^

[Bluedeep]

( bon oui y a les struct qui sont aussi des types valeur
Mais quand même ...

Les struct (dont DateTime), les types intrinsèques(tous les types numériques + char et bool), les enums sont des types "valeur", les classes, les delegate, les tableaux sont des types "référence".

Les types "valeur" sont alloués sur la stack, les types "référence" sont alloués sur le heap.

[DonQuiche]

Ce n'est qu'une intuition mais, à mon avis, il y a un problème de fond dans la conception qui entraîne cet usage étrange des génériques dont l'intérêt ici est annulé par addData qui va nécessiter un cast/boxing puis un autre cast/unboxing. Difficile de se prononcer sans savoir à quoi sert tout ce code et en particulier qui enregistre les données, et qui les consomme et comment. Mais tout ça ressemble aux machins tordus que je pondais il y a plusieurs années juste après l'introduction des génériques. A l'époque je râlais beaucoup contre les génériques. Curieusement, aujourd'hui je les trouve parfaits alors qu'ils n'ont pas changé.

[brachior]

Si tu veux savoir,

Les Module donnent des données aux Output
Qui les donnent aux Input (pas du même Module ^^)
Et les Input donnent ensuite les données aux Module

[DonQuiche]

Oui mais ça ne répond à rien. ^^

Pourquoi stockes-tu ces données, que deviennent-elles ensuite ? Je ne veux pas savoir si X donne les données à Y, je veux connaître le but de ce code et savoir ce qu'il advient des données (sont-elles imprimées ? sont-elles additionnées ?).

[tomlev]

Les types "valeur" sont alloués sur la stack, les types "référence" sont alloués sur le heap.

Cette affirmation est relayée à tort et à travers, mais elle est inexacte... les types valeur peuvent être allouées sur la pile (contrairement aux types référence qui sont alloués sur le tas), mais ce n'est pas toujours le cas.

Ce qui est plus important à noter, c'est que les types valeur sont passés par valeur (i.e. tout l'objet est copié quand on le passe en paramètre où qu'on l'affecte à une variable), alors que les types référence sont passés par référence (i.e. on passe une référence vers le même objet)

Pour des explications plus détaillées, voir l'excellent blog d'Eric Lippert :
The Stack Is An Implementation Detail, Part One
The Stack Is An Implementation Detail, Part Two
The Truth About Value Types

Ce n'est qu'une intuition mais, à mon avis, il y a un problème de fond dans la conception qui entraîne cet usage étrange des génériques dont l'intérêt ici est annulé par addData qui va nécessiter un cast/boxing puis un autre cast/unboxing.

Je suis assez d'accord, ça me turlupine depuis le début de cette discussion...

Soit on connait le type des données à manipuler, et dans ce cas on peut effectivement utiliser des génériques, soit on ne le connait pas et dans ce cas l'utilisation d'interfaces non générique est parfaitement adaptée...