JDK 7: Proposition 3 : Comparer les énumérations [Débat]

[vbrabant]

Aujourd'hui :

Code java :

1
2
3
4
5
enum Size { SMALL, MEDIUM, LARGE }

if (mySize.compareTo(yourSize) >= 0)
    System.out.println(“You can wear my pants.”);

Demain :

Code java :

1
2
3
4
5
enum Size { SMALL, MEDIUM, LARGE }

if (mySize > yourSize)
    System.out.println(“You can wear my pants.”);

[yann2]

Bonsoir

Je suis pour mais les cas d'utilisation semblent très limités, non ?

Qui irait comparer la classique énumération saison {AUTUMN, SPRING, WINTER, SUMMER} ?

yann

[gronono]

Bonjour,

Je suis contre. Qu'est ce qui définit la notion d'ordre pour une énumération ?

Par exemple si j'ai une énumération des modes de paiement:
ESPECES, CHEQUES, CB.

Pourquoi ESPECES < CHEQUES me donnerai true (ou false) ?????

Si on veut un opérateur de comparaison, il faut l'implémenter et non se baser sur la déclaration.

A+
Gronono

[Napalm51]

Contre, pour les même raisons que gronono.

[n!co]

Cela n'invente rien non plus !
http://java.sun.com/j2se/1.5.0/docs/...ml#compareTo(E)

La question serait plus de savoir si cet opérateur se basera sur la méthode compareTo() ?

[austin P.]

plutot contre

à mon sens la methode compareTo() à plus de sens que l'operateur > ou <

comme le dit gronono la sémantique est plus importante

[gronono]

Envoyé par n!co

Cela n'invente rien non plus !
http://java.sun.com/j2se/1.5.0/docs/...ml#compareTo(E)

La question serait plus de savoir si cet opérateur se basera sur la méthode compareTo() ?

Contrairement à la méthode compareTo, l'opérateur < n'a pas de javadoc. Et donc ne précise pas que l'ordre est l'ordre des déclarations.

Je pense que ce n'est pas une bonne chose qu'une énumération implémente Comparable. on devrait pouvoir le faire à la demande comme pour les autres classes.

D'ailleurs à partir de maintenant, je vais systèmatiquement rédefinir cette méthode pour renvoyer une UnsupportedOperationException.

A+
Gronono

[OButterlin]

Ben, j'aime pas, je trouve que ça ne facilite pas la lisibilité du code.
Je préfère

Code :

1
2
 
if ( mySize > size.LARGE )

Dans tous les cas, je ne comprends pas l'exemple... quel lien entre mySize, yourSize et Size ?
D'un autre côté, je n'ai jamais utilisé d'enum, ça vient certainement de là...

[verbose]

J'ai voté pour, mais en y réfléchissant à deux fois, je suis plutôt contre pour les même raisons que gronono.

[Jester]

J'ai voté contre, la sémantique de > n'est pas valide pour toutes les enum.

Après je serais bien pour la surcharge d'opérateur mais c'est un autre débat.

[le y@m's]

Je suis contre pour les mêmes raisons que celles énoncées précédemment.

Cependant, je serais d'accord si cette fonctionnalité était optionnelle.
Pouvoir comparer des enums est intéressant, mais cela dépend de leur implémentation et il me semble donc primordiale que ce soit le développeur qui spécifie explicitement si une enum est comparable (via un mot clé ou un implements Comparable ou autre).

[elitost]

Une lisibilité bizarre pour cette option.

[nicorama]

Envoyé par gronono

Contrairement à la méthode compareTo, l'opérateur < n'a pas de javadoc.

+1
Plus j'avance dans les propositions, plus je suis épaté par les contres-arguments soulevés. Ca sent le vécu quand même

[yann2]

bonsoir,

La structure de contrôle foreach n'a pas de Javadoc et on est bien content de pouvoir l'utiliser (pourtant la classe Iterable et la méthode iterator ont une javadoc). Le tout est de connaitre le mécanisme qu'il y a derrière !

Et la javadoc de compareTo de la classe Enum est claire !

[edit]
et en fait j'aimerai bien que cette fonctionnalité (sauf pour le == ) soit étendue à toutes les classes qui implémentent Comparable !! M'enfin je lance ça comme ça sans en avoir étudier les tenants et aboutissants On pourrait, par exemple comparer des objets de type date le plus naturellement du monde.
[/edit]

yann

[gronono]

En fait, il y a deux sujets différents dans cette proposition.

Si l'opérateur < revient à faire .compareTo alors je suis plutot pour. On pourrait ainsi comparé deux objets et je pense que c'est même plus lisible.
Par exemple si j'ai un objet Personne qui implémente Comparable alors je peux faire :

Code :

1
2
3
4
5
6
 
Personne p1 = ...
Person p2 = ..
if (p1 < p2) {
 // Faire qqchose
}

Serait équivalent au code :

Code :

1
2
3
4
5
6
 
Personne p1 = ...
Person p2 = ..
if (p1.compareTo(p2)) {
 // Faire qqchose
}

Le second sujet est que les énumérations implémentent Comparable. Sur ce point je suis contre pour les raisons evoquées ci-dessus.

A+
Gronono

[natha]

Ca risque de devenir ambigüe. Je suis contre également.

[woodwai]

Pour mais à condition que ce soit basé sur compareTo comme on le fait déjà pour le tri automatique des Collection.

Ça reviendrait à ajouter un compareTo dans la class Object (comme le equals) qui serait par défaut une comparaison du hashCode, on aurrait ensuite les comparateurs >, <, <=, >= qui se baserait sur la valeur retourné par le compareTo.

En fait, c'est quand même bien compliqué donc j'hésite ...

[ludosoft]

Pour moi ça craint aussi. Faut pas vouloir faire avec un type énuméré ce qu'ont ferait avec un entier.

Code :

1
2
enum Humain { HOMME, FEMME, BB }
HOMME+FEMME=BB ?

[Traroth2]

Contre. En fait, c'est le retour des méthodes operator du C++, avec leur cortège de défauts. Le principal : la yntaxe créé la confusion, et on a tendance à y mettre un contenu implicite qui n'est peut-être pas le contenu de l'operateur. Les bénéfices étant par ailleurs plutôt faibles (écriture un peu plus compacte), je vote contre sans hésiter.

[xavlours]

Pour moi c'est une forme de surcharge des opérateurs, qui a été refusée dès le début de java, donc pourquoi s'y mettre maintenant ? Les interfaces de Comparator et Comparable sont utiles et bien faites, et trouve ça plus modulaire : on choisit nous même le Comparator pour trier une liste, par exemple. Cette proposition incite les développeurs à fournir des classes qui se basent directement sur l'opérateur.