Discussion :

[maa]

Bonjour,

Je me demande pourquoi il n'est pas possible, en .net, de dire qu'une classe implémente automatiquement une interface si sa signature correspond à celle de l'interface et sans qu'on est besoin de préciser explicitement qu'elle l'implémente.

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
interface IInterface
{
string PropertyA {get; set;}
}
 
class ClasseA
{
public string PropertyA {get; set;}
}

Ça serait bien si on pouvait directement utiliser une instance ClasseA en tant que IInterface. C'est pas que je sois fainéant au point de ne pas vouloir écrire ":IInterface", mais bien souvent on aimerait qu'une classe implémente une interface (et elle l'implémente effectivement au niveau de la signature), mais on ne peut pas accéder aux sources. Évidement le dp adaptateur est possible mais il n'est pas léger à implémenter ni très efficace puisqu'on crée un wrapper pour chaque classe à implémenter.

Je ne vois que peux d'avantage à être obligé d'écrire : ":IInterface"
- Il est vrai que cela force à être plus lisible. On peut voir très rapidement quelles interfaces implémentent une classe. Si on n'avait la possibilité de ne pas l'écrire, on aurait certainement un code moins lisible.
- Cela permet d'être sûr qu'il n'y a pas d'ambiguïté. 2 classes pourraient avoir une même signature mais les membres pourrait avoir des significations totalement différentes. En implémentant une interface on la relie à un ensemble de classe ayant un sens commun.

Avec l'arrivée de c#4 et des types dynamiques, je pense que les choses sont un peu différentes car on peut maintenant invoquer un membre d'une classe sans qu'il n'existe, la vérification étant faite à l'exécution. Je pense que cela est de toute façon plus dangereux que de risquer d'invoquer un membre existant qui n'a pas le sens attendu.

Que pensez vous de tout cela ? Pensez-vous que l'on pourra implicitement implémenter une interface avec l'arrivée du framework 4 ?

Merci d'avance pour vos remarques.

[tomlev]

- Cela permet d'être sûr qu'il n'y a pas d'ambiguïté. 2 classes pourraient avoir une même signature mais les membres pourrait avoir des significations totalement différentes. En implémentant une interface on la relie à un ensemble de classe ayant un sens commun.

A mon avis, à lui seul ce point justifie qu'on déclare explicitement l'interface implémentée...

[maa]

A mon avis, à lui seul ce point justifie qu'on déclare explicitement l'interface implémentée...

oui mais avec c#4, il y a ce point :

Avec l'arrivée de c#4 et des types dynamiques, je pense que les choses sont un peu différentes car on peut maintenant invoquer un membre d'une classe sans qu'il n'existe, la vérification étant faite à l'exécution. Je pense que cela est de toute façon plus dangereux que de risquer d'invoquer un membre existant qui n'a pas le sens attendu.

[Gold Bug]

Je me demande pourquoi il n'est pas possible, en .net, de dire qu'une classe implémente automatiquement une interface si sa signature correspond à celle de l'interface et sans qu'on est besoin de préciser explicitement qu'elle l'implémente.

Probablement parce que personne n'y avait jamais pensé avant toi

Blague à part, je pense qu'un compilo comme celui de C# serait techniquement capable de faire ce que tu dis.
Mais ouvrir cette porte a de nombreux inconvénients :
- Quand tu implémentes une interface qui est partagée entre plusieurs projets/collègues, si l'interface change, tu dois adapter ton code sinon il ne compiles plus. Dans le cas que tu présentes, la classe va continuer à compiler, mais elle plantera à l'exécution. C'est beaucoup plus difficile à débugger et à maintenir.
- Les diagrammes de classes auront-il encore un sens, sachant qu'on se retrouvera avec des classes qui n'implémentent pas les interfaces en C# alors qu'elles les implémentent sur le diagramme UML ?
- Le reverse-engineering devient mission impossible (bon d'accord, c'est souvent déjà le cas )

[maa]

Je pense en effet que le comportement par défaut devrait rester celui qu'il est.
Mais on pourrait ajouter un mot clé "implicit" devant la déclaration d'une interface.
Une telle interface ne pourrait alors être utilisée par des méthodes que si celle-ci déclare ses paramètres du type de l'interface comme "implicit"

Donc quelque chose de ce style :

implicit interface IInterface
{
string PropertyA {get; set;}
}

class ClasseA
{
public string PropertyA {get; set;}
}

public void AMethod(implicit IInterface p)
{
}

//et on pourrait appeler comme ceci :
AMethod(new ClassA());

Cela permettrait d'éviter d'écrire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public void AMethod(object p)
{
    if(p is type1)
        var p1 = p as type1
        ...
    else if(p is type2)
        var p2 = p as type2
        ...
    else if(p is type3)
        var p3 = p as type3
        ...
    endif
}

Qui risque beaucoup plus de planter à l'exécution puisqu'on ne fait même pas de vérification sur la signature de la classe...

[Guulh]

C'est possible en C++ avec les templates. En gros, si tu écris en C++ (me souviens plus de la syntaxe exacte)

Code :

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

public T Machin<T>(T item) { return item + 1; }

le compilo ne dira rien si tu n'utilises jamais la méthode. Par contre, dès que tu l'utilises sur un certain type (disons int), le compilo va créer une version de la méthode propre au type int, et donc

Code :

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

public int Machin(int item) {return item +1; }

, qui compile correctement parce que l'on peyut ajouter 1 à un int. Mais c'est parce que les template sont très différents des generics, malgré une syntaxe et un usage voisin. Ici, si tu appelles la fonction Machin sur un type T à toi qui n'a pas d'operator+ prenant un int, tu te prendras une jolie erreur de compil bien incompréhensible.

Ce que tu demandes serait possible en C++ :

Code :

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

1
2
3
4
5
public void AMethod<T>(T p)
{
  ...
  ... p.PropertyA;
}

Parce que en fait t'auras autant de méthodes AMethod que de type différents avec lequel tu l'as appelée.

[maa]

Je ne comprends pas trop pourquoi on sait que p à une propriété A.

[Guulh]

C'est parce que les template C++ ne sont que des macros, en fait. En soi, elles n'ont pas à être correctes syntaxiquement. S'il y a dans ton code

Code :

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

1
2
3
4
5
void f()
{
   Machin(4);
   Machin("bob");
}

Le compilo va créer deux fonctions machin, l'une pour int, l'autre pour string ; et c'est après les avoir créées qu'il va essayer de les compiler et vérifier leur syntaxe.
Alors qu'en C#, le compilo peut indépendamment des éventuels appels vérifier la syntaxe d'une méthode générique

'fin je parlais de tout ça pour dire ton idée est loin d'être bizarre, puisqu'elle est réalisable (au moins) en C++

[davcha]

Les interfaces implicites, c'est prévu pour une future version de c#.

[maa]

Les interfaces implicites, c'est prévu pour une future version de c#.

C#4 ??

[tomlev]

C#4 ??

je ne crois pas, je ne l'ai pas vu dans les nouveautés du langage...
http://jlambert.developpez.com/tutor...eautescsharp4/

[maa]

Comment sais-tu que c'est prévu pour une future version ?

[Guulh]

Les blogs des concepteurs de C# sont déjà une bonne source d'infos bien fraîches http://blogs.msdn.com/ericlippert/ par exemple.

Où l'on apprend que C#2 était un ensemble hétéroclite d'évolutions du langage, C#3 entièrement consacré à LINQ ; C#4 est dans la lignée du 2, un ensemble de nouvelles fonctionnalités diverses sans gros changement conceptuel (alors que LINQ, c'était un gros morceau).

Mais rien sur les "interfaces implicites".

[davcha]

Ils en ont parlé dans la vidéo présentant c#4.

[maa]

Code :

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

 	 Ils en ont parlé dans la vidéo présentant c#4.

Des interfaces implicites ?

[davcha]

oui

[lysiandad]

Ils en ont parlé dans la vidéo présentant c#4.

Je peux me tromper, mais peut-être que davcha fait un amalgame entre le souhait de maa et ce qui est effectivement présenté dans la video (et d'autres sources) : les variables "dynamic" ; en effet, comme cela apparait dans la synthèse (très bien faite, au fait, amha) des principales nouveautés C# 4 de Lambert, le compilo C# acceptera un mot clé dynamic qui lui indiquera, précisément, de ne pas se soucier du type "statique" de la variable (c-à-d connu lors de la compilation)... puisque justement... inconnu. La résolution du nom du membre d'instance invoqué via la variable qui reference la cible de l'appel objet se fera à l'execution.

En clair, ceci, en C# 4 :

Code :

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

1
2
3
 
/* ligne 1*/ dynamic obj = ...// ici, on va chercher l'instance sur laquelle on va travailler
/* ligne 2*/ obj.MaMethode(3);

voudra dire pour le compilateur : "ne te soucie pas du type effectif de obj, mais génère le code (MS)IL nécessaire, qui, à l'execution, decouvrira (utilise pour cela System.Reflection) si une méthode MaMethode existe sur le type de l'instance obj, acceptant (au moins) un parametre de type compatible avec Int32 ; et si ce n'est pas le cas à ce moment là, génère une exception"

En clair : C# 4, sera, entre autres, en mariage presque parfait entre le late binding et l'early binding, en permettant de choisir entre les deux, early binding par défaut (les types statiques sont connus du compilo) et late binding en option, au besoin, avec types statiques inconnus du compilo, mais assumés en tant qu'inconnues.

Je dis "presque parfait" car voir les limitations liées a l'usage de "dynamic" avec les autres constructions syntaxiques et semantiques provenant de C# 1, 2, 3 ; Lambert ne manque pas d'en parler.

My 2 cents.

[lysiandad]

[...]
Je dis "presque parfait" car voir les limitations liées a l'usage de "dynamic" avec les autres constructions syntaxiques et semantiques provenant de C# 1, 2, 3 ; Lambert ne manque pas d'en parler.

My 2 cents.

Pardon pour cette auto réponse, mais pour la petite histoire, sans vouloir vous raconter ma vie (y a un groupe sur facebook rigolo "36 15 ta vie", btw... ), sachez que je suis de très près moi aussi, a mes heures perdues les evolutions de conception du langage C# depuis le debut, puisque j'ai "la chance" (sauf pour certaines migraines...) d'avoir vecu / de vivre deux coincidences a la fois :

1) la theorie des langages en general, et de ceux de programmation, objet ou non, c'est mon "dada" depuis longtemps ;

2) sans le connaitre personnellement malheureusement ( ), je "connais" un peu l'esprit du monsieur Anders H., architecte/concepteur principal de C#, et avant cela, de Delphi (1995-1997), et vous trouverez peut etre interessant de savoir que nos amis qui continuent de developper sous Delphi ont pour la plupart vu au moins une fois dans Delphi Object Pascal le fameux type "Variant" qui est traité par le compilo Delphi de maniere très similaire au compilo C# 4 a venir, mais qui est moins puissant : "Variant" en Delphi ne fonctionne que si la cible de l'appel non typé est un objet OLE/Automation (interface IDispatch implementée) ; dans le cas de C# 4, le mot clé "dynamic" sera utilisable a travers tout le systeme de type (a l'execution) supporté par le CLR, pas seulement des objets automation... "CQFD" ;

"dynamic", c'etait donc tres certainement dans les cartons d'Anders depuis longtemps pour C#, car l'experience de "Variant" dans Delphi s'est revelee souvent tres utile... il n'a fait là que "rechauffer" une vieille idee qu'il a mise en oeuvre dans son Object Pascal a succès. Mais je suppose qu'en 99/2000, la priorite c'etat d'abord pour lui et MS de definir un C# 1.0 "propre", avant d'introduire ce genre de "babiole orientée confort". C'est comme cela que je me l'explique en tout cas, ce n'est qu'une vague supposition.

(euh... oui, je triche un peu, j'ai été technicien support langages Borland spécialisé sur Delphi entre 95 et 97 précisément... )

[lysiandad]

Pardon pour cette auto réponse, [...]

(Re-pardon, etc)

Bon, cela dit peut etre que maa trouvera utile ce "dynamic" en C# 4, comme workaround a l'absence "d'interfaces implicites" telles qu'il les imaginait, et l'amalgame de davcha est neanmoins une intuition interessante entre les deux semantiques exprimées.

Cependant, je peux donc vous dire que je suis donc de près l'evolution de C# et je n'ai rien vu de publié qui présente exactement cela, explicitement comme "interfaces implicites" avec des détails sur la maniere dont le compilateur C# 4 le gèrera. "dynamic" n'est pas "très, très" éloigné de ce que souhaite maa, mais au sens strict... eh bien cela reste tout de même assez eloigné, si on veut bien regarder de près.

Je terminerai ma participation a ce fil en vous donnant un bon tuyau sur les gens avec les lesquels Anders travaille et valide ses idees neuves ou "rechauffées" : faites donc un peu de google sur "C omega" (clin d'oeil a "C sharp") ; "C omega" a servi (sert?) d'epreuve de concept pour les evols sur C # N+1 ; ce ne sont autres que les gens de MS Research ; bcp de leurs travaux (synthèses) sont dispo en liens vers des PDF / PostScript ; MS Research est le "labo" collectif d'experimentation pour Anders et ses collègues ; vous pouvez souvent avoir des infos sur leurs preoccupations / objectifs genre presqu'un an avant même que les CTP / les tech days parlent de tels sujets... a bons entendeurs...

[ EDIT ]
Curieux vous aussi, comme moi ? Pour en savoir plus, meme wikipedia a une page utile sur le sujet :

http://en.wikipedia.org/wiki/Cω

[maa]

Merci pour ces réponses lysiandad !

J'espère quand même que les interfaces implicites seront dans le framework 4. Est-ce que la vidéo que vous avez vue présente toutes les nouveauté de ce framework ou est-ce que la liste n'est pas encore arrêtée ?

En tout cas, les interface implicites serait tout à fait dans la logique du framework 4 je trouve, car cela permet plus de flexibilité mais en restant au maximum dans le early binding. Avec les interfaces implicites, on pourrait dans certains cas faire ce qu'on fait avec les type dynamic mais en ayant l'auto-complétion et sans utiliser de reflexion.

De plus ça serait très utiles pour le traitement d'un bon nombre de classes provenant de Microsoft Office Tools qui ont souvent les mêmes propriétés mais aucune interface ou classe de base en commun.
Si vous suivez de près l'évolution de c#4, vous noterez aussi qu'il va dans le sens de mieux l'intégrer à VSTO (paramètre optionnels, nommés,...) et là encore les interfaces implicites seraient plus que bienvenus... Reste à convaincre Microsoft...