Java - Pourquoi aucune surcharge de méthode basée sur le type de retour?

Question

Je sais que ce n'est pas possible, mais est-ce que quelqu'un peut expliquer pourquoi Java a choisi de ne pas supporter cela? Je pose la question parce que je viens de me trouver dans une situation où je pense que ce serait bien d’avoir.

Answer 1

Etant donné que vous n'êtes pas obligé de capturer la valeur de retour d'une méthode en Java, le compilateur ne peut alors pas décider quelle surcharge utiliser. Par exemple

 boolean doSomething() { ... }

int doSomething() { ... }

doSomething(); // which one to call???
 

Answer 2

Un aspect intéressant de cette question est le fait que le langage Java interdit de surcharger les méthodes seulement par le type de retour. Mais pas la JVM:

Notez qu'il peut y avoir plus d'un la méthode de correspondance dans une classe, car tandis que le langage Java interdit à un classe de déclarer plusieurs méthodes avec la même signature, mais différents les types de retour, la machine virtuelle Java ne fait pas. Cette souplesse accrue dans la machine virtuelle peut être utilisée pour mettre en œuvre les différentes fonctionnalités de la langue. Par exemple, covariante les retours peuvent être mis en œuvre avec pont méthodes; l' pont de la méthode et la méthode substituée aurait le même signature, mais différents types de retour.

De: Classe.getMethod(String, Classe...)

Answer 3

J'ai demandé pourquoi ils ne prennent pas en charge cette aussi. Bien sûr, si vous ignorez la valeur de retour, le compilateur n'a aucun moyen de savoir que vous avez voulu. Mais c'est la même ambiguïté qui se pose avec passage de valeurs null. Comme:

String doSomething(String s) { ... }
String doSomething(Integer s) { ... }
...
String out=doSomething(null);

Dans ce cas, le compilateur se plaint juste que l'appel est ambigu, et que vous avez à résoudre par la coulée de la valeur nulle, comme:

String out=doSomething((String)null);

On pourrait faire la même chose avec la surcharge par le type de retour:

String getSomething() { ... }
Integer getSomething() { ... }
...
Integer n=getSomething();

ne serait sans doute appel à la deuxième fonction.

getSomething();

d'être ambigu (et dans cet exemple, probablement inutile, à moins d'avoir des effets indésirables, mais c'est une autre histoire), de sorte que vous auriez à dire:

(String) getSomething();

De façon plus réaliste, peut-être:

if ((String) getSomething()==null) ...

Mais c'est le cas simple. Je peux voir un compilateur-écrivain ne pas vouloir soutenir cette raison, il pourrait devenir très compliqué à comprendre à rien d'autre qu'une simple affectation. Par exemple, pensez à:

String getSomething() { ... };
Integer getSomething() { ... };
String getOtherthing() { ... };
...
if (getSomething().equals(getOtherthing())) ...

Le compilateur aurait pour comprendre que c'est à la fois la Chaîne et de Entier ont est égal fonctions, donc soit on est en vigueur à ce point. Alors il faudrait remarquer que getOtherthing est une Chaîne de caractères, Entier et.equals(String) est peu probable, et c'est probablement ce que l'auteur voulait, c'était de la Chaîne.equals(String). Possible, mais à ce point, je commence à voir que, dans le cas général, cela pourrait être une bête.

Et puis, supposons que nous ajoutions:

Integer getOtherthing() { ... };

Qu'est ce que le compilateur ne S'déclaration? Il pourrait utiliser la Chaîne des versions de ces deux fonctions, ou le nombre Entier, mais pas la Chaîne de l'un et de l'Entier de l'autre. À ce stade, il faudrait insister sur un coulé à dire, je suppose. Mais la complexité est vraiment sortir de la main.

Et si c'est dur pour le compilateur de savoir ce que tu veux vraiment dire, imaginez ce que ce serait comme pour un autre programmeur qui ne peut rechercher toutes les signatures de fonction aussi vite que le compilateur peut.

Answer 4

Je pense que vous pouvez trouver une solution dans le lien ci-dessous.

http://stackoverflow.com/questions/442026/function-overloading-by-return-type

Answer 5

C'est parce que vous êtes libre d'ignorer la valeur de retour.