Là y'a un truc qui m'échappe.
 
J'ai un TreeSet dans lequel je mets des objets Xyz qui implementent Comparable.
Mon implémentation de Comparable est pas "nickel", dans la mesure ou elle n'est pas cohérente avec le equals(), mais d'après la javadoc c'est un comportement acceptable meme si non recommandé.
 
Vla t'y pas que j'ai deux une instance de Xyz, qu'on va appeller A et B.  
 
A.compareTo(B) renvoie 0, mais A.equals(B) renvoie false.
 
je prend mon set, je fais
 
set = new TreeSet();
set.add(A);
set.remove(B);
 
et vlan, mon set est vide.
 
 

 
>> benou la petite bite soi disant, elle t'emmerde!!!!

je t'ai fait un exemple vite fait
 

 
voila en fait le prob c'est que le remove se fait en fonction du résulat de compareTo et pas des adresses donc chez toi comme A et B ont 0 comme résultat de compareTo bah il va supprmier A meme si tu lui demandes de supprimer B
pouet

ben... oui.
c'est nul.
il pourrait checker le equals ce porc.

ouaip
je ferais bien une implémentation perso :x

non mais doit y'avoir une explication spa possible...
 
là j'ai encore mieux: mon objet n'implemente plus Comparable, he ben vlan il se viande en essayant de caster des Comparable
 
 
(edit: Comparable par Comparator )

bon ben

dans mon cul, quoi.

bha, c'est normal,
 
Si tu veux pas que ca fasse ca, tu te débrouilles pour que ton coparable ne retourne jamais 0, ou bien mieux, tu utilises un Comparator qui utilie le comparable mais qui retourne -1 dans le cas où le compareTo retourne 0 ...

peut être mais elle s'explique pas beaucoup  

et ca c'est vraiment très mal ! Problème de design !
 
Si tu veux pouvoir ordonner tes instances mais qu'il ne s'agit pas d'un ordre naturel, il vaux largement mieux fournir un Comparator que d'implémenter Comparable. En inner classe static par exemple ou dans une classe à côté. C'est ce qu'ils ont fait pour String par exemple : y a l'ordre naturel et une instance static de Comparator qui permet de trier en case non-sensitive.

Je vote +1 (sauf qu'une classe n'est pas inner si elle est static, elle est simplement nested JLS 8.1.2)  
 
En fait il y a confusion entre classe et role dans le domaine de l'objet actuel. En gros un objet peut avoir plusiseurs rôles, dont un principal, c'est vis-à-vis de ce rôle qu'on va définir equals, hashCode et compareTo. Une classe peut avoir des rôles secondaires, qu'on exploitera par des composants "branchables" (pluggables).
 
Hélas, en java la modularité des collections est assez limitée, les seuls point de branchement est Comparator pour les TreeSet et les clefs de Map.
 
mais dans d'autres frameworks, on peut externaliser la fonction de hachage, l'égalité, les clef pour les maps (c'est aussi le cas en java) ou avoir une clef interne à la classe (ainsi, par ex., le map va chercher tout seul le nom d'une personne dans l'objet pour l'utilisr comme clef) et les fonctions de comparaison.

je ne connaissais pas la différence de signification de ces 2 mots
 
Hélas, en java la modularité des collections est assez limitée, les seuls point de branchement est Comparator pour les TreeSet et les clefs de Map.
mais dans d'autres frameworks, on peut externaliser la fonction de hachage, l'égalité, les clef pour les maps[/citation]
 
Pour celà tu peux faire des inner classes (qui seront ajoutées dans les collections à la place de l'objet lui même) et qui définissent les méthodes hashCode, equals et éventuellement compareTo.
 
Mais il est vrai que ce méchanisme n'est pas présent de base dans le framework Collection mais il est facilement implémentable (2 interfaces + surcharge des classes du framework).

1) je pensais que tu connaissait mais j'ai joué le lourd comme picure de rappel pour un peu tout le monde.
 
2) oui, mais le problème est pris à l'envers dans ce cas.  
Tentage d'explication (pas forcément pour toi d'ailleur) : tu ne files pas à la collection l'objet mais un truc représentant un de ses rôles. à la sortie de la collection, il va falloir faire une opération pour récupérer l'objet. Alors que customiser la collection une fois pour toutes n'engage pas les clients de la collection. en plus ça ne fonctionne que pour les classes et pas pour les interface.
d'autre part, l'abus d'allocation de petits objets assassine le garbage collector.

Bha oui je sais, c'est de la bidouille ... mais si on considère que le framework collection contient des briques de base, c'est pas illogique de vouloir étendre ces fonctionnalités de base.
 
Quand à la remarque sur le GC ... ce n'est certainement pas une chose à prendre en compte quand on cherche un design propre ...

d'ailleur on devrait peut-être éliminer Singleton et Flyweight du vocabulaire de patterns.

http://java.sun.com/j2se/1.4.2/doc [...] ng.Object)

 
autrement dit, c'était expressement que ma compareTo n'était pas "synchro" avec mon equals.
je savais pas encore que cet idiot de TreeSet me ferait pas un equals avant de virer mon objet !
 
 
edit: le not etait en italique mais comme tout est italique dans une citation (c'est nouveau?), je l'ai mis en gras

Dans un set il n'est pas possible de mettre plusieures fois le même élément non ? Avec un comparateur comme ça, du point de vue du set les 2 objets sont egaux. Et par consequence, il ne devrait pas être possible de mettre à la fois A et B.

justement, on pinaille sur "le même élément" là.

 
et alors ??? on te dit que c'est pas recommandé et toi tu t'empresse de le faire... T'étonnes pas qu'on te dise que t'as un problème de design
 
Moi je trouverai illogique que le TreeSet se serve de equals alors qu'on lui passe un Comparator explicitement. Ca aurait même aucun sens ...
 
et le fait que ce soit pas "required" ca veut dire que ton programme pourra s'executer pas qu'il va s'executer logiquement ...

"Effective STL"  Item 19: Understand the difference between equality and equivalence.  
 
Avant, j'aurais conseillé ce livre a toute personne faisant du C++. Grace à ce thread je vais aussi le conseiller à toute personne faisant du Java