Discussion :

[pierreact]

Il suffit de lire La discution qui se tient ici pour voir que cela apporterait plus de confusion que de reel progres, Pensons y, CompareTo est deja implemente et semble clair, Les exemples donnes sont mal compris, ce qui me pousse encore plus a penser que ca serait a l'origine de plus de confusions.... Ce n'est pas souhaitable pour un language de prog...

Non.

[nlegriel]

J'ai voté pour. En effet, je pense que les types énumérés du langage Java devraient fonctionner de la même façon que les types énumérés du langage Pascal.

En langage Pascal, les éléments d'un type énuméré sont naturellement ordonnés par l'ordre dans lequel ils sont déclarés. Si on écrit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

type jours = ( lundi, mardi, mercredi, jeudi, vendredi, samedi, dimanche );

on a

lundi < mardi < mercredi < jeudi < vendredi < samedi < dimanche

A en juger la documentation du JDK 5 (http://java.sun.com/j2se/1.5.0/docs/...l#compareTo(E)), le type énuméré du Java a été pensé de la même façon que pour le langage Pascal.

Pourquoi n'aurions-nous pas simplement la même chose en Java ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
enum Jour { LUNDI, MARDI, MERCREDI, JEUDI , VENDREDI, SAMEDI, DIMANCHE }

(...)

Jour jour1;
Jour jour2;

(...)

if (jour1 < jour2) {
  (...)
}

if (jour1 < Jour.JEUDI) {
  (...)
}

Je vois que des gens ont soulevé la question de savoir quel sens donner à la comparaison entre les constantes d'un type énuméré. A mon avis, il n'y a pas de question à se poser et il n'y a pas de comparateur à implémenter. Je ne pense pas non plus que l'on puisse parler de notion de surcharge d'opérateur puisqu'il n'y a qu'un seul sens possible à donner à l'opérateur de comparaison.

Si on se trouve dans une situation où la notion d'ordre sur les éléments n'a pas de sens alors il ne faut pas utiliser une énumération mais un ensemble (concept qui n'impose pas la notion d'ordre).

[djo.mos]

Contre.
Je crois que mes raisons ont déjà été citées plus hat: aucune relation d'orde triviale ne peut être défini sur les enums, à l'inverse des entiers par exemple.

[Patriarch24]

Contre bien entendu. Bien malin celui qui peut définir un ordre total sur n'importe quelle énumération. Implémenter Comparable, qui est fait pour, me semble une meilleure idée. Cette proposition ajouterait un sucre syntaxique inutilisable dans la plupart des cas, donc c'est généraliser quelque chose qui ne l'est pas (généralisable ).

[ripounet]

A mon avis c'était dès le départ une mauvaise idée que les enum soient automatiquement Comparable. N'en rajoutons pas :p

[pseudocode]

contre.

Ca ressemble a une revendication des habitués de l"enum du C dans lequel les valeurs sont forcement des "int".

[g_rare]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Serait équivalent au code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Tout à fait d'accord sur les 2 sujets (donc je ne vote pas) : je voterais "pour" si la question était de généraliser les raccourcis syntaxiques de comparaison entre Comparable, mais "contre" si la question était de conserver les énumérations Comparable.

[Nataouze]

Bonjour,

A vrai dire je trouve l'intérêt plutôt limité, même s'il est vrai que comparer des jours comme le décrit nlegriel peut trouver une utilité certaine.

Je dis pour car concrètement, c'est une possibilité de plus offerte pour gérer certains types d'énumérations, libre à nous de s'en servir ou pas.

[Thorna]

A priori, je dirais contre, pour la raison habituelle qu'on n'a pas obligatoirement un ordre dans une énumération.

Mais:

A mon avis c'était dès le départ une mauvaise idée que les enum soient automatiquement Comparable. N'en rajoutons pas :p

Et donc, justement, si le langage veut rester cohérent, on doit pouvoir utiliser < = > .
Je serais donc plutôt pour finalement, sachant que c'est au programmeur d'utiliser cette possibilité quand elle a un sens.

[nonilastar]

Bonjour,

Evidemment si > et < correspondent à la méthode compareTo, c'est vrai que cela deviendrait plus intuitif et donc plus facile d'utilisation. Sans cette correspondance, ça n'a aucune pertinence.

[drazel]

je suis contre également. Une énumération n'implique pas forcément de relation d'ordre.
De plus il me semble que le nom de la méthode "compareTo" est assez parlant pour les cas où on en a besoin pour ne pas ajouter une nouvelle syntaxe pouvant elle preter à confusion.

[tnodev]

Bonjour

J'aime bien les enums, je suis plutôt pour...

Les valeurs des types énumérés implique forcément une relation d'ordre, celle de sa position dans le type énumérés.
Ça ne me choque pas de pouvoir simplement comparer la position de l'enum par rapport à un autre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
enum Message{
INFO,
WARNING,
ERROR,
FATAL;
 
    @Override
    public String toString() {
        if ( this > WARNING) {
        //Au secours
        }
         ...
    }
}

[natha]

Ça ne me choque pas de pouvoir simplement comparer la position de l'enum par rapport à un autre.

=>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum Message{
INFO,
WARNING,
ERROR,
FATAL;
 
    @Override
    public String toString() {
        if ( this.ordinal() > WARNING.ordinal()) {
        //Au secours
        }
         ...
    }
}

T'as gagné !

[tnodev]

T'as gagné !

Ouais !!!
J'ai gagné quoi ? des chocolats, des places pour l'Euro... ?

[fabszn]

Hello,

Je suis plutôt contre.

Pour moi, le besoin de comparaison pour un type énuméré est savoir s'ils sont égaux et pas de définir une relation d'ordre particulier.

Si l'énumération a besoin de définir un ordre (exemple avec niveau de log), alors c'est le développeur qui doit prendre ça en charge.

[natha]

Si l'énumération a besoin de définir un ordre (exemple avec niveau de log), alors c'est le développeur qui doit prendre ça en charge.

Pour utiliser l'ordre naturel il y a #ordinal() qui peut être utilisé, ça fait 10 caractères de plus que ce qui est demandé dans cette proposition, c'est pas la mort je pense.

[tnodev]

Pour utiliser l'ordre naturel il y a #ordinal() qui peut être utilisé, ça fait 10 caractères de plus que ce qui est demandé dans cette proposition, c'est pas la mort je pense.

Si, c'est ça le progrès, pouvoir se passer d'une dizaine de caractère

[Kalite]

Je suis pour

Mais il est vrai cependant que les opérateur <, >, >= et <= n'ont aucun sens. Seul == et != sont correcte à mon sens.

[Alec6]

il y a peu etre un interet quelque part, dans la technique, dans les couches basses, dans les limbes...

Un objet n'est généralement pas indexé dans son ensemble, surtout si cet ensemble est défini en extension, comme c'est le cas pour les énumérations.

Lorsque l'on défini l'ensemble des planètes de notre système solaire, on fait une énumération, et on a tendance à les indexer du soleil vers les aliens.
Notre énumération n'est donc pas une liste définie en compréhension, et de ce fait la comparaison par indexation n'a pas de sens.

Conclusion: je suis contre (et contre le javascript aussi).

D'autre par, quand on compare deux planètes, c'est rarement sur cet aspect, qui n'est même pas un attribut de l'objet planète. Cette variable se trouve dans une autre table normalement. On fait des comparaisons sur des variables masses, spectre etc... et donc le compareto devient un myPlanete.comparteTo(yourPlanete, attribut). On a un problème de contexte. Le compareto est vide de sens. Sinon il faudrait pouvoir tagger un attribut comme étant le discriminant.

[tnodev]

Un objet n'est généralement pas indexé dans son ensemble, surtout si cet ensemble est défini en extension, comme c'est le cas pour les énumérations.

D'autre par, quand on compare deux planètes, c'est rarement sur cet aspect, qui n'est même pas un attribut de l'objet planète. Cette variable se trouve dans une autre table normalement. On fait des comparaisons sur des variables masses, spectre etc... et donc le compareto devient un myPlanete.comparteTo(yourPlanete, attribut). On a un problème de contexte. Le compareto est vide de sens. Sinon il faudrait pouvoir tagger un attribut comme étant le discriminant.

Le but n'est pas de disserter s' il y a un intérêt ou non à comparer des enums (et actuellement on peut la faire par rapport à la position de l'enum), mais de savoir si le supérieur/inférieur peut remplacer le compareTo() pour gagner une dizaine de caractère !