Re: Les vrais ajouts

Quelle est la logique dans le code suivant:

MyObject foo = new MyObject(param);
MyObject bar = new MyObject(param2);
OtherObject toto = new OtherObject(param1);
foo == bar; // vrai. ou faux. Ca dépend.
toto == bar; // vrai. ou faux. ça dépend. Ou pas. Faut voir au runtime en fait.

Note: == peut avoir été surcharge.
Ou pas.

Et last but not least, que fait le code suivant:

private void bla(T foo) {
 for(T object in this.list) {
 if(object == foo){ // vrai. ou faux. mais peut être pas. Parcourt potentiellement un graphe monstrueux et tire 500 objets d'une base de données par lazy loading. En fait on sait pas. D'ailleurs on sait pas si le mec qui a écrit chercher le meme pointeur ou un objet équivalent.
 // wouhou!
 }
 }
}

Note: == peut avoir été surcharge.
Ou pas.

Certes ton example est étonnant au premier abord, mais, il est parfaitement spécifie et tout le monde sait exactement pourquoi il fonctionne comme il fonctionne.
Tu lit le code tu sais exactement ce que ça va donner. Et tu sais aussi comment l'écrire pour que ça donne exactement ce que tu veux.
Cela dit, l'exemple reste parfaitement logique, l'utilisation avec new donne exactement le résultat escompte. Quand tu by-pass new, t'as des résultats bizarre, mais hé, t'as pas instantie ces objects toi meme, hein? Alors? De quoi tu te plains?

Le gros problème de la method bla écrite plus haut, est que personne ne peut dire ce que cette méthode va faire, et pire encore, c'est fondamentalement impossible de dire ce que cette méthode est censée faire. L'intention n'est pas exprimable dans le langage, parce qu'un meme symbole a 2 sémantique complètement opposée.
Ca dépend du contexte et des objets qui sont passes en entrée, et ça c'est fondamentalement mauvais.

Ca a pas l'air de te plaire, mais il ya une enorme difference entre == et equals.
Utiliser le meme symbole selon le contexte pour l'un ou l'autre est une GROSSE erreur de design.
Sans compter qu'un jour, tu vas vouloir a la fois utiliser l'égalité de pointeur et l'égalité de valeur, et t'auras l'air bien malin avec ton == surcharge.

Partant de la, il faut bien les différencier.

Au passage, bon courage pour implementer ta surcharge de == avec des proxy. Et c'est pas comme si les proxy était un concept étrange en java.

Quand tu regardes les choses:
- Le premier est une simple égalité de pointeur. Pas de code qui tourne, on compare juste deux entiers. == est parfaitement adapte, concision et ça correspond bien au model mental.
- Le deuxième implique une logique métier, potentiellement très couteuse (tu peux avoir a parcourir une partie de ton graphe d'objet pour déterminer l'égalité). Logique métier implique une méthode. Un symbole == n'est pas adapte car il n'est pas associe a cette notion d'exécution de code.

Le choix est parfaitement logique et adapte dans le cas général. Maintenant, il se trouve que les chaines constantes subissent qq optimisations, est ce que ça veut dire qu'il faut laisser tomber un design qui marche tres bien pour le reste des classes?
Va falloir argumenter sérieusement parce que beaucoup ont besoin de faire la différence entre égalité de pointeur et égalité de valeur, surcharge == ne va que t'apporter des problemes impossible a résoudre, par design.

Java a au moins le mérite d'intégrer ce concept dans le langage, amuse toi a écrire du code un tant soit peut générique (genre sélection automatique dans une dropdown) en ActionScript, t'es oblige de te baser sur des conventions parce que le langage n'est pas assez riche.

If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.