Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Actualités

  • Blog de Cyril DURAND, passionné de JavaScript, Ajax, ASP.net et tout ce qui touche au developpement Web Client-Side.

    View Cyril Durand's profile on LinkedIn

    hit counters

[MSIL] surcharge de méthode avec même signature mais type de retour différents

En C# il n'est pas possible d'avoir deux méthodes ayant une signature identique qui différent seulement par le type de retour.

public class Foo { public int Bar() { return 0; } public String Bar() { return "pouet"; } }

En MSIL c'est possible. Le code ci dessous compile parfaitement.

.assembly Foo{} .module Foo.dll .class public CFoo { .method public static int32 Bar() { ldc.i4.0 ret } .method public static string Bar() { ldstr "Toto" ret } }

Lorsqu'on fait un appel de méthode en MSIL, on spécifie le nom complet de la méthode :

call int32 CFoo::Bar() // ou call string CFoo::Bar()

Que se passe t'il en C# ? Comment spécifier la méthode que l'on veut utiliser ?

Untitled

L'IntelliSense de Visual Studio nous propose la méthode Bar qui retourne un String, mais si nous utilisons cette méthode.

String s = CFoo.Bar();

Nous avons une erreur de la part de compilation :

Untitled2

J'ai essayé en castant la méthode (String)CFoo.Bar() mais même erreur. J'ai tenté VB, l'IntelliSense ne me propose même pas de méthode Bar.

Quelle est alors l'utilité de ce type de surcharge ? J'en ai trouvé qu'une seule, cela permet aux obfuscateurs de complexifier le code. En effet, si notre classe possède des méthodes GetPerson() et GetCompany() qui retournent respectivement une List<Person> et une List<Company>, un obfuscateur pourra utiliser le même nom pour renommer ces méthodes.

Est-ce que C# doit pouvoir utiliser/créer de tels surcharges ?

Techniquement, l'inférence de type nous permettrait de ne pas avoir trop d'ambigüité, si cela ne suffit pas on pourra toujours caster explicitement, afin de séléctionner la bonne méthode.
Conceptuellement, bien que dans certains cas cela puisse être utile, je ne pense pas que cela soit une bonne chose, cela risque de complexifier le code pour peu. L'utilisation des generics, nous permet dans la majorité des cas d'obtenir des solutions alternatives.

Et vous qu'en pensez vous ? Est-ce que le futur compilateur devra prendre ce cas en compte ?

Posted: vendredi 18 avril 2008 14:01 par cyril
Classé sous : , , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

FREMYCOMPANY a dit :

Je trouve que le compilateur devrait supporter ces méthodes mais pas permettre  d'en créer.

Pour syntaxe, je dirais "foo.Bar() as String" ou "foo.Bar(as String)() // foo.Bar

<as(String)>()"

D'ailleurs VB devrait gérer les indéterminations dûes à la casse de la même manière.

Si on a foo.BAR et foo.bar, foo.bar devrait pointer vers foo.BAR (+avertissement) et foo.BAR devrai pointer vers foo.BAR (+avertissement). foo.Bar devrait retourner une erreur, sauf si BAR et bar sont différentiables par les arguments passés. Dans ce cas, il devrait trouver le plus appropriés des deux et changer la casse automatiquement.

# avril 18, 2008 18:42

FREMYCOMPANY a dit :

lol, je me rends compte que je me suis gourré dans mon truc sur foo.bar et foo.BAR, m'enfin vous m'aurez compris, je l'espère. En gros, quand deux membres ont la même casse, la casse compte, sauf si la signature des membres permet des les différencier via leur utilisation (type, paramètres, ...)

# avril 18, 2008 18:52

Jb Evain a dit :

“Quelle est alors l'utilité de ce type de surcharge ? J'en ai trouvé qu'une seule, cela permet aux obfuscateurs de complexifier le code.”

Il y en a un autre. Un grand. C'est donner la possibilité aux gens qui implémentent des langages sur la CLR d'avoir la possiblité de le faire, si leur langage est assez expressif et/ou capable de gérer ça.

Ce qui fait que cette partie du langage ne sera pas CLS compliant, et donc aura du mal à interoperer avec d'autres langages, mais au moins, ça laisse la possibilité.

# avril 18, 2008 23:01

FREMYCOMPANY a dit :

@Evain : En effet, tu as surement raison sur ce point.

# avril 19, 2008 12:07

cyril a dit :

En effet, vu comme ca c'est un avantage non négligeable. Connais tu un langage qui permet ce genre de chose ?

j'ai testé, C#, VB, J#, C++ CLI et Boo, aucun ne le permet.

# avril 19, 2008 13:00

Jb Evain a dit :

Haskell par exemple. Peut être ML, donc il faudrait essayer voir avec F#. Mais après ça dépend aussi de l'implémentation du compilo, qui pourrait changer par exemple le nom de la méthode en fonction de sa signature pour les différencier.

Bref, ce qui est important, c'est de laisser la possibilité, il y a des tas de trucs en IL qu'on ne peux pas écrire avec des langages un peu traditionnel, mais la CLI se voulant multi langages, à tout intérêt à ne pas s'arrêter là dessus.

# avril 19, 2008 17:47
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- un Pacman en Silverlight 2b2 par Pierrick's Blog le il y a 4 heures et 45 minutes

- Une table -> deux entity types sans colonne discriminante en base, gestion des relations par Matthieu MEZIL le il y a 12 heures et 44 minutes

- ssdl view et TPT par Matthieu MEZIL le 07-05-2008, 02:04

- L'injection SQL n'est PAS un problème QUE pour les développeurs web ! par CoqBlog le 07-05-2008, 01:08

- Un outil pour réaliser des animations WPF basées sur des équations de Bézier par Perspective le 07-04-2008, 21:45

- Sandcastle et CodePlex : le verdict par CoqBlog le 07-04-2008, 20:53

- ssdl view et TPH par Matthieu MEZIL le 07-04-2008, 19:12

- Webcasts sur le Parallel Framework disponibles par Matthieu MEZIL le 07-04-2008, 17:26

- [Silverlight] - Comprendre et Débuter avec Silverlight par Danuz le 07-04-2008, 12:41

- SharePoint : Nouvel article sur l'exportation et Importation de sites SharePoint par Blog Technique de Romelard Fabrice le 07-04-2008, 01:00