[Article] Présentation de la classe Tuple du .NET Framework 4

**ijk-ref** · 15/01/2010, 11h15

Envoyé par oyigit

Lorsqu'on manipule un objet de type ParametresRechercheClients, on sait (et visual studio nous le montre bien) qu'on traite des paramètres de recherche de patients, on sait à quoi est destiné l'objet..., alors qu'avec un type anonyme...

Mais justement le type anonyme est à utiliser quand le nom du type n'a pas d'importance... car autrement la construction d'une classe ordinaire est fait pour ça !

D'ailleurs c'était tout l'intérêt de la création générique du Tuple : Il évite aux développeurs d'écrire chacun de leur coté leur propre Tuple qui vont rentrer en conflit lors de la mise en commun d'un projet. Et oui ils l'appelles tous "Tuple" car le nom du type n'a pas d'important mais seulement ses propriétés.

Par exemple dans le cas où une méthode doit avoir en sortie plusieurs variables.
Au lieu d'avoir 3 ou 4 "out" l'idéal est de sortir tout ça par le "return" dans un classe dont le nom n'a aucune importance.

**anthyme** · 15/01/2010, 12h42

Envoyé par Jérôme Lambert

Je pense que ça devrait être possible de pouvoir utiliser un var "type" de retour d'une méthode.

Code :

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

1
2
3
4
var MaVarMethode()
{
   return new {PropString = "hello", PropInt = 2010};
}

A la compilation, mon type anonyme donnera une classe concrète, c'est le principe des objets anonymes.

Ce n'est pas possible car le compilateur ne pas faire une déduction a partir du corps de la méthode ... le seul moyen de savoir ce qu'il se passe c'est de l executer ...

Comment tu veux que le compilateur fasse dans ce cas la sinon :

Code :

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

1
2
3
4
5
6
7
var MaVarMethode(bool test)
{
   if(test)
      return new {PropString = "hello", PropInt = 2010};
   else
      return new {PropBool = true, PropInt2 = 2010};
}

A quoi va ressembler ton type en sortie ?

**ijk-ref** · 15/01/2010, 13h51

Envoyé par anthyme

Ce n'est pas possible car le compilateur ne pas faire une déduction a partir du corps de la méthode ... le seul moyen de savoir ce qu'il se passe c'est de l executer ...

Ca tombe bien car ce n'est pas du tout ce que j'ai écrit !

Le type est parfaitement déclaré par la forme "( Type1 Name1, Type2 Name2, etc... )"

Le mot clé "var" n'est pas utilisé. Le mot clé "var" garde toujours son utilisation en local.

Par exemple le type "KeyValuePair<int, string>" pourrait être remplacé par "(int Key, string Value)"

Edit : excuse j'ai cru que tu répondais à mon dernier message

**anthyme** · 15/01/2010, 14h09

Envoyé par ijk-ref

Ca tombe bien car ce n'est pas du tout ce que j'ai écrit !

Ca tombe bien ce n'etait pas a vous que je répondais

**ijk-ref** · 15/01/2010, 14h14

Et comment trouvez-vous ma proposition ?

Si elle fait un peu trop "Jean-Claude Van Damme donne des cours de physique-moléculaire" faut le dire !

**tomlev** · 15/01/2010, 15h06

Envoyé par Jérôme Lambert

(thomas, c'est toi ?!!! => private joke avec l'équipe dvp

)

Non c'était pas moi... mais quelqu'un de tout aussi sensé

Envoyé par Jérôme Lambert

Après, pourquoi n'est-il pas possible d'utiliser ce type d'écriture ? Il n'y que les équipes de Microsoft qui ont la réponse suite à leurs très nombreuses deiscussions brainstorming, design, etc.

Pour ce genre de question, je recommande vivement la lecture du blog d'Eric Lippert.
Mais bon, la raison pour laquelle telle ou telle fonctionnalité n'est pas implémentée est presque toujours la même : ça coute trop cher en temps et en ressources par rapport aux avantages que ça apporte. La moindre petite fonctionnalité de rien du tout demande des spécifications, du développement, des tests très poussés, de la documentation, etc... donc il faut que ça en vaille vraiment la peine, ils implémentent pas tous les petits gadgets qui leur passent par la tête.

Envoyé par ijk-ref

Et comment trouvez-vous ma proposition ?

Moi j'aime bien... tu peux toujours suggérer ça à Microsoft, mais je doute qu'ils l'intègrent. Ou alors peut-être dans C# 10

**ijk-ref** · 15/01/2010, 15h27

Envoyé par tomlev

Moi j'aime bien... tu peux toujours suggérer ça à Microsoft, mais je doute qu'ils l'intègrent. Ou alors peut-être dans C# 10

Je ne pense pas qu'ils résisteront aussi longtemps pour ne pas l'utiliser.

Je pense qu'il suffit de vérifie qu'il n'y ait pas de conflit dans la grammaire... ensuite tout est déjà implanté grâce au "var"

Où puis-je réaliser cette proposition. Il y a forum, un sujet de discussion approprié pour ma question ?

**tomlev** · 15/01/2010, 15h34

Envoyé par ijk-ref

Où puis-je réaliser cette proposition. Il y a forum, un sujet de discussion approprié pour ma question ?

https://connect.microsoft.com/
Mais ne te fais pas trop d'illusions

**ijk-ref** · 15/01/2010, 15h43

Envoyé par tomlev

https://connect.microsoft.com/
Mais ne te fais pas trop d'illusions

Pourquoi donc ! "Windows 7 c'est moi !"

**Jérôme Lambert** · 15/01/2010, 16h55

Envoyé par anthyme

Ce n'est pas possible car le compilateur ne pas faire une déduction a partir du corps de la méthode ... le seul moyen de savoir ce qu'il se passe c'est de l executer ...

Comment tu veux que le compilateur fasse dans ce cas la sinon :

Code :

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

1
2
3
4
5
6
7
var MaVarMethode(bool test)
{
   if(test)
      return new {PropString = "hello", PropInt = 2010};
   else
      return new {PropBool = true, PropInt2 = 2010};
}

A quoi va ressembler ton type en sortie ?

J'ai pas dit que c'était possible sans changement au préalable du compilateur. (et j'ai pas dit non plus que ce que j'ai proposé est une fonctionnalité que je voudrais voir intégrée dans C#, qu'on se comprenne bien

).

Par contre, quand tu dis que le compilateur ne peut pas déduire le type de retour sur base du corps de la méthode : tu es bien sûr ?!

Comment ça se fait que ceci ne compile pas ?

Code :

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

1
2
3
4
int MaMethode()
{
   return "";
}

Ou si je réprends ton exemple, comment ça se fait que ceci ne compile pas non plus ?

Code :

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

1
2
3
4
5
6
7
int MaVarMethode(bool test)
{
   if(test)
      return 1;
   else
      return "";
}

**anthyme** · 18/01/2010, 10h20

Envoyé par Jérôme Lambert

Par contre, quand tu dis que le compilateur ne peut pas déduire le type de retour sur base du corps de la méthode : tu es bien sûr ?!

Comment ça se fait que ceci ne compile pas ?

Code :

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

1
2
3
4
int MaMethode()
{
   return "";
}

Ou si je réprends ton exemple, comment ça se fait que ceci ne compile pas non plus ?

Code :

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

1
2
3
4
5
6
7
int MaVarMethode(bool test)
{
   if(test)
      return 1;
   else
      return "";
}

Justement il a déduit le type de retour a partir de la définition, puis une fois ce type déduis il vérifie que tous les return correspondent bien au type défini

**Jérôme Lambert** · 18/01/2010, 11h37

Envoyé par anthyme

Justement il a déduit le type de retour a partir de la définition, puis une fois ce type déduis il vérifie que tous les return correspondent bien au type défini

Le compilateur est donc bien capable de repérer les différents return dans le corps d'une méthode/propriété et en déduire les types renvoyés. On est d'accord

**ijk-ref** · 18/01/2010, 12h10

Envoyé par Jérôme Lambert

Le compilateur est donc bien capable de repérer les différents return dans le corps d'une méthode/propriété et en déduire les types renvoyés. On est d'accord

Mais heureusement il ne le fait pas... même pas pour les "var" en local... car ce serait un bazar monstre !

C'est pourquoi il faut définir la typage avec cette écriture "(Type1, Name1, Type2 Name2, ...)" qui éviterait l'écriture de classes utilisées seulement pour la lecture de leurs propriétés.

**anthyme** · 19/01/2010, 13h58

Envoyé par Jérôme Lambert

Le compilateur est donc bien capable de repérer les différents return dans le corps d'une méthode/propriété et en déduire les types renvoyés. On est d'accord

Les types des objets renvoyés par les "return" sont vérifiés par rapport au type spécifié dans la définition mais on ne peut pas faire le mouvement inverse car le nombre de return peut être multiple et de types différents tu ne peux donc pas déduire LE type renvoyé vu qu'il peut y en avoir PLUSIEURS

Imaginons qu'il regarde dans les types qui sont dans les return pour déduire le type à renvoyer et qu'il renvoi le type le plus "général" (si tu as un classe A et une classe B qui hérite toutes les 2 de C, le type déduis de return new A(); et return new B(); serai donc C)

Je vais te donner un exemple correct (car je suis d'accord que mon ancien exemple qui retournait un int et une string c'est incorrect syntaxiquement) mais où le type est impossible à déduire :

Soit 2 classes A et B et 2 interface IC et ID:

Code :

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

1
2
class A : IC, ID {}
class B : IC, ID {}

Code :

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

1
2
3
4
5
6
7
public var Method(bool aOrB)
{
   if(aOrB)
      return new A();
   else
      return new B();
}

Alors quel type de retour va être déduis ici ? IC ou ID ? Le compilateur est complètement incapable de le deviner ... On ne peux donc pas déduire le type de retour avec les "return"

**Jérôme Lambert** · 19/01/2010, 14h26

Déjà, on parle de choses qui seraient possibles uniquement avec modification du compilateur (pour rappel).

Si une telle évolution était possible, le compilateur devrait signaler une erreur à la compilation dans le cas où des des return renvoient des types différents. Ca me parait simple comme règle.

Après, par rapport à ton nouvel exemple. Il est clair pour moi que les types que tu tentes de renvoyer sont différents.

Si tu désirerais "typer le var" en IC par exemple, suffit d'utiliser le casting comme on le fait depuis toujours :

Code :

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

1
2
3
4
5
6
7
public var Method(bool aOrB)
{
   if(aOrB)
      return (IC)new A();
   else
      return (IC)new B();
}

A aucun moment, tu tentes de renvoyer un IC dans ton exemple, le compilateur n'a aucune raison de tenter une résolution de conflit.

Et si on suit toujours ton raisonnement, pourquoi le code suivant compile et s'exécute correctement avec le framework 3.5 ?

Code :

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

var monObjetAnonyme = new { InstanceA = new A(), InstanceB = new B(), InstanceAIC = (IC)new A() };

**anthyme** · 21/01/2010, 10h37

Envoyé par Jérôme Lambert

Déjà, on parle de choses qui seraient possibles uniquement avec modification du compilateur (pour rappel).

Si une telle évolution était possible, le compilateur devrait signaler une erreur à la compilation dans le cas où des des return renvoient des types différents. Ca me parait simple comme règle.

Après, par rapport à ton nouvel exemple. Il est clair pour moi que les types que tu tentes de renvoyer sont différents.

Si tu désirerais "typer le var" en IC par exemple, suffit d'utiliser le casting comme on le fait depuis toujours :

Code :

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

1
2
3
4
5
6
7
public var Method(bool aOrB)
{
   if(aOrB)
      return (IC)new A();
   else
      return (IC)new B();
}

A aucun moment, tu tentes de renvoyer un IC dans ton exemple, le compilateur n'a aucune raison de tenter une résolution de conflit.

Et si on suit toujours ton raisonnement, pourquoi le code suivant compile et s'exécute correctement avec le framework 3.5 ?

Code :

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

var monObjetAnonyme = new { InstanceA = new A(), InstanceB = new B(), InstanceAIC = (IC)new A() };

et je ne vois pas bien pourquoi ton code ne devrait pas compiler, ce sont 3 variable différente d'un type anonyme qui peuvent donc avoir 3 type différent pas comme un retour de fonction qui ne peux avoir qu'un seul type...

Forcer l'utilisation de cast pour toujours préciser le type de retour c'est un gros retour en arriere je vois plus bien l'interet de se casser la tete a mettre var comme type de retour si c pour se casser la tete a spécifier le type sur chaque return

**ijk-ref** · 21/01/2010, 11h00

Envoyé par anthyme

et je ne vois pas bien pourquoi ton code ne devrait pas compiler, ce sont 3 variable différente d'un type anonyme qui peuvent donc avoir 3 type différent pas comme un retour de fonction qui ne peux avoir qu'un seul type...

Forcer l'utilisation de cast pour toujours préciser le type de retour c'est un gros retour en arriere je vois plus bien l'interet de se casser la tete a mettre var comme type de retour si c pour se casser la tete a spécifier le type sur chaque return

Voila ton problème : tu n'as pas du tout compris comment fonctionne "var"

"var" n'est pas un typage dynamique !

Tout est résolu à la compilation. Autrement il ne sera pas possible après un "var" de connaitre les propriétés d'un objet

**anthyme** · 21/01/2010, 15h28

Je n'ai jamais dit que c'était dynamique ...

Var est censé être une aide à l'écriture par déduction de type à la compilation, quand on sort un mot clef qui est sensé simplifié la vie il faut que ce soit carré
Perso je vois plus de perte que de gain de

Code :

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

1
2
3
4
5
6
7
public var Method(bool aOrB)
{
   if(aOrB)
      return (IC)new A();
   else
      return (IC)new B();
}

par rapport a

Code :

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

1
2
3
4
5
6
7
public IC Method(bool aOrB)
{
   if(aOrB)
      return new A();
   else
      return new B();
}

Le deuxieme est quand même plus explicite, plus concis et plus propre ...

**ijk-ref** · 21/01/2010, 17h25

Envoyé par anthyme

Perso je vois plus de perte que de gain de (...) par rapport a (...)
Le deuxieme est quand même plus explicite, plus concis et plus propre...

Tout à fait mais ce n'est ce qu'il a voulu dire

C'était juste un exemple où "var" pourrait fonctionner.

... et puis c'est de votre faute aussi ! Je vous ai dit de ne pas partir dans le "délire" sur l'utilisation de "var" sur des fonctions. Ce débat ne mènera à rien !

Le seul, le grand et unique débat possible c'est sur le choix d'une classe/structure permettant de remplacer "Tuple" !

Et entre :
- KeyValuePair<int, string>
- Tuple<int, string>
- (int Key, string Value)

c'est tout vu pour moi

**anthyme** · 22/01/2010, 13h34

Envoyé par ijk-ref

Tout à fait mais ce n'est ce qu'il a voulu dire

C'était juste un exemple où "var" pourrait fonctionner.

... et puis c'est de votre faute aussi ! Je vous ai dit de ne pas partir dans le "délire" sur l'utilisation de "var" sur des fonctions. Ce débat ne mènera à rien !

Le seul, le grand et unique débat possible c'est sur le choix d'une classe/structure permettant de remplacer "Tuple" !

Et entre :
- KeyValuePair<int, string>
- Tuple<int, string>
- (int Key, string Value)

c'est tout vu pour moi

Moi j'aime bien votre idée sauf pour le return.

je verrai bien un return dans ce style :

Code :

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

1
2
3
return new (1,"toto");
// ou 
return (1,"toto");

plutot que de retourner un type anonyme...

L'avantage du tuple c qu'on peut renvoyer une liste de tuple dans le type de retour

[Article] Présentation de la classe Tuple du .NET Framework 4

Framework .NET

Partager

Partager