Pourquoi deux méthodes ne peuvent-elles pas être déclarées avec la même signature même si leurs types de retour sont différents?

Question

en double: Function overloading by return type?

---

Peut-être que cela est une question très stupide, mais je ne comprends pas pourquoi je ne peux pas déclarer deux méthodes qui ont la même signature quand ils ont différents types de retour. Je reçois une erreur de compilation qui indique que la classe définit déjà un membre avec les mêmes types de paramètres.

(Il est évident que la façon dont je me sers dans mon code n'est pas aussi simple que mon code exemple ... mais je pense qu'il a l'idée à travers.)

Suis-je manque quelque chose au sujet de la conception OO que fait ce que j'essaie de faire un anti-pattern OOP? Sûrement le compilateur devrait être en mesure de déterminer quelle méthode j'essaie d'utiliser tant que je lui dis spécifiquement lequel je veux.

Compte tenu MyClass myClass = new MyClass(); je me attendrais le code suivant au travail:

double d = myClass.MyMethod(); 
string s = myClass.MyMethod(); 

je me attendrais le code suivant pour avoir des problèmes:

var v = myClass.MyMethod(); 

Mais même dans le cas de var devrait entraîner une erreur de compilation.

Quelqu'un peut-il voir ce que je fais mal ici? Je suis plus qu'heureux d'être corrigé. :-)

Answer 1

Il est à cause de la contrainte de type .

Supposons que vous avez les fonctions suivantes:

int x(double); 
float x(double); 

double y = x(1.0); 

devrait vous appeler maintenant, lequel des deux prototypes, surtout si elles font deux choses totalement différentes? Fondamentalement, il a été décidé très tôt dans la conception du langage d'utiliser uniquement le nom et les arguments de la fonction pour décider quelle fonction réelle est appelée, et nous sommes bloqués avec cela jusqu'à l'arrivée d'un nouveau standard.

Maintenant, vous avez étiqueté votre question C# mais je ne vois rien de mal à concevoir un langage qui puisse faire ce que vous suggérez. Une possibilité serait de marquer comme une erreur des commandes ambiguës comme ci-dessus et forcer l'utilisateur à spécifier ce qui devrait être appelé, comme la coulée:

int x(double); 
float x(double); 
double y = (float)(x(1.0)); // overload casting 
double y = float:x(1.0);  // or use new syntax (looks nicer, IMNSHO) 

Cela pourrait permettre au compilateur de choisir la bonne version. Cela fonctionnerait même pour certaines questions que d'autres réponses ont soulevées. Vous pouvez activer l'ambiguïté:

System.out.Println(myClass.MyMethod()); 

dans le spécifique:

System.out.Println(string:myClass.MyMethod()); 

Cela peut être possible de s'ajouter à C# si ce n'est pas trop loin dans un processus standards (et Microsoft écouterez) mais je Ne pensez pas beaucoup de vos chances de l'ajouter à C ou C++ sans une énorme quantité d'efforts. Peut-être que le faire comme une extension à gcc serait plus facile.

Answer 2

Une signature de méthode est le nom et les paramètres d'entrée (type & order) uniquement. Le type de retour ne fait pas partie de la signature. Ainsi, deux méthodes avec le même nom et les mêmes paramètres d'entrée sont identiques et entrent en conflit les unes avec les autres.

Answer 3

Rien ne vous empêche d'appeler votre méthode sans "capturer" le type de retour. Il n'y a rien de vous empêche de le faire:

myClass.MyMethod(); 

Comment le compilateur savoir qui appeler dans ce cas?

Edit: Ajoutant à cela, en C# 3.0, lorsque vous pouvez utiliser var, comment vous le compilateur savoir quelle méthode d'appel lorsque vous faites ceci:

var result = myClass.MyMethod(); 

Answer 4

Quelle variable, le cas échéant, à laquelle vous attribuez la méthode ne peut pas informer le compilateur de la méthode à utiliser. Imagine:

Chaîne message = "Resultat" + myClass.MonMethod();

Answer 5

Parce que le type de retour n'est pas si important lors de l'appel d'une méthode. Cela conduirait à l'ambiguïté dans de nombreux cas à avoir des méthodes ne différant que par le type de retour. Vous ne pouvez pas stocker le résultat dans une variable du tout, ou faire quelque chose comme ceci:

System.out.Println(myClass.MyMethod()); 

Le compilateur n'a aucun moyen de savoir qui des méthodes que vous vouliez appeler.