On peut l'expliquer comme on veut, en terme d'usage c'est juste de la merde.
J'ai pas dit que c'était bien. De toute façon, en Java, quand on compare des Object avec ==, c'est que l'on sait ce que l'on fait. La base que l'on apprend, c'est de comparer les objets avec equals, et String ne fait pas exception à la règle.
J'aimerais bien voir du code où on a intérêt de tester les références de String
Utiliser == est bien plus rapide que d'utiliser equals. Il y a des outils/API qui manipulent beaucoup de String (XML, ...), et là ça devient intéressant de pouvoir rapidement savoir si 2 String ont la même valeur.
parce que bon l'égalité dans le cas général c'est quand même ==
== teste l'égalité des référence quand tu l'utilises sur des objets. Le cas général, c'est == pour les types de base, equals pour les objets.
D'ailleurs, je sais plus qu'elle est la vrai raison de la non inclusion de la surcharge d'opérateur. Je crois que c'est tellement con que je ne retiens pas.
Je ne la connais pas, mais comme toi, je regrette aussi qu'on ne puisse pas le faire.
[^] # Re: Les vrais ajouts
Posté par calvin2001 . En réponse au journal Java 7 est dispo !. Évalué à 3.
J'ai pas dit que c'était bien. De toute façon, en Java, quand on compare des Object avec
==, c'est que l'on sait ce que l'on fait. La base que l'on apprend, c'est de comparer les objets avecequals, et String ne fait pas exception à la règle.Utiliser
==est bien plus rapide que d'utiliserequals. Il y a des outils/API qui manipulent beaucoup de String (XML, ...), et là ça devient intéressant de pouvoir rapidement savoir si 2 String ont la même valeur.==teste l'égalité des référence quand tu l'utilises sur des objets. Le cas général, c'est==pour les types de base,equalspour les objets.Je ne la connais pas, mais comme toi, je regrette aussi qu'on ne puisse pas le faire.