Discussion :

[Alec6]

C'est vrai c'est de la philo; c'est juste que ca me sidère comme on peut perdre en sémantique avec le temps. Java a la beauté d'un langage structuré, adapté à la modélisation. Une énumération impléménte comparable et la javadoc nous dit:

This interface imposes a total ordering on the objects of each class that implements it. This ordering is referred to as the class's natural ordering, and the class's compareTo method is referred to as its natural comparison method.

Conclusion vous ne pouvez faire que des enums avec des listes (et pas des bags), pour respecter le contrat. Pour énumerer n'est pas "ordonnancer" !

Pour conclure si on remplace compareTo par < et >; peut etre faudrait il généraliser le cas; car à force d'avoir des exceptions dans la grammaire on finira par écrire en français (langage que je ne maitrise toujours pas)

[nlegriel]

Bonjour,

Il y a quelque chose qui m'interpelle dans ce débat : est-ce que quelqu'un s'est intéressé à la définition d'énumération ?

Sun s'est appuyé sur une certaine définition qui met en jeu une relation d'ordre totale. A partir de là, la question est de savoir si l'utilisation des symboles < et > sur les littéraux des énumérations apporte une amélioration au langage Java.

Il est possible que chacun ait sa propre définition d'énumération. En effet, certains affirment avec conviction qu'on ne peut pas définir de notion d'ordre sur les énumérations, d'autres trouvent peu pertinente la notion d'ordre et d'autres encore trouvent qu'elle n'est qu'un "plus".

Je vous renvoie au dictionnaire de developpez.com sur une définition d'énumération : http://dico.developpez.com/html/2934...numeration.php.

Vous constaterez qu'il s'agit ici non pas d'une définition d'énumération mais d'une définition d'un stéréotype prédéfini d'UML. Cela ne donne pas la définition d'énumération mais c'est déjà intéressant car UML reprend des concepts généraux de l'informatique. J'ai surligné en rouge ce qui me paraît le plus remarquable dans cette définition :

Stéréotype indiquant un type de données prédéfini ou défini par l'utilisateur qui possède une liste ordonnée de littéraux énumérés.

On voit qu'ici, la notion d'ordre fait partie de la définition. Je n'ai malheureusement pas d'autre dictionnaire d'informatique sous la main pour voir ce qu'il existe comme définitions d'énumération. Est-ce que quelqu'un peut proposer d'autres définitions ?

Personnellement, j'avais l'habitude d'appeler ordre d'énumération l'ordre dans lequel les éléments sont énoncés dans une déclaration d'énumération. Cela me paraissait être une notion d'ordre triviale.

J'avais l'impression d'aller dans le même sens que les concepteurs des API Java. Cependant, si j'ai voté pour la proposition de comparaison des énumérations c'était sans enthousiasme particulier. Je la considérais comme un simple prolongement de ce qui existe déjà (voir mon dernier message dans ce débat avec l'exemple du langage Pascal).

Chacun peut penser ce qu'il veut de la pertinence de la relation d'ordre sur les énumérations. Si elle est introduite dans le langage, il n'est pas obligatoire de l'utiliser. Le compareTo existait déjà sur les énumérations. Ajouter la possibilité d'utiliser à la place le symbole de comparaison ne me choquerait pas. Je trouve bien que l'on ajoute un moyen de rendre le code plus lisible en remplaçant un appel de méthode par une notation bien connue et bien plus naturelle.

En effet, ce qui me paraît être un des aspects les plus importants de la programmation, ce n'est pas de rendre le code plus concis, c'est simplement la transmissibilité du travail entre les informaticiens (surtout dans le cadre de projets en équipe ).

[natha]

Le principe des Enum Java est bâti sur cette notion d'ordre à n'en point douter, sinon des méthodes telles que EnumSet.range() n'existeraient pas.

Y a-t'il eu une raison technique ou philosophique pour ne pas introduire l'utilisation des opérateurs < et > pour la comparaison d'Enum ?

Comme discuté, s'ils le font pour les Enum, ils devront le faire pour n'importe quelle classe implémentant "Comparable", est-ce une bonne chose ? A vrai dire je ne sais pas, je serais tenté de dire non car il y a par exemple le problème des références nulles.

[vbrabant]

Le principe des Enum Java est bâti sur cette notion d'ordre à n'en point douter, sinon des méthodes telles que EnumSet.range() n'existeraient pas.

Y a-t'il eu une raison technique ou philosophique pour ne pas introduire l'utilisation des opérateurs < et > pour la comparaison d'Enum ?

Joshua Bloch a expliqué durant le BOF à Javapolis qu'il avait oublié de transcrire ce § dans la spec Java. Du coup, comme cela n'était pas dans la spec, cela ne pouvait pas être implémenté. En proposant cela, il veut réparer son erreur.

Comme discuté, s'ils le font pour les Enum, ils devront le faire pour n'importe quelle classe implémentant "Comparable", est-ce une bonne chose ? A vrai dire je ne sais pas, je serais tenté de dire non car il y a par exemple le problème des références nulles.

Malheureusement, cela n'est pas possible. Enum a un comportement fortement différent des autres classes. Ainsi, un enum est TOUJOURS bien représenté une seule fois. Du coup, on peut avec les enum TOUJOURS utiliser ==, comme on le ferait pour n'importe quel primitive. Ce qui fait qu'il n'y a aucun problème à ce que > et < soit supporté par enum. Car il pourra aussi supporté >= <= == !=
Par contre, il ne sera JAMAIS possible que l'on ait ce comportement là avec des objets de classes de type Interger ou Long. Puisqu'on ne peut pas dire que equals() est identique à == pour ces objets, on ne peut du coup pas accepter les < et > du fait qu'on ne pourra accepter les <=, >=, ==, !=.
Je ne sais pas trop si je suis clair.

Vincent

[natha]

Je ne sais pas trop si je suis clair.

J'ai tout pigé, c'était très clair, merci

[Bollagain]

Contre. De mon point de vue, le commentaire de xavlours (porte ouverte vers une forme degradé de surcharge des opérateurs) reste un point trés fort. En terme de lisibilité du code, les opérateurs de comparaison me paraissent problèmatrique quand l'ordre des elements comparé n'est pas absolument évident. Ainsi, lire dans un code un truc du type ci dessous a pour effet de me plonger dans des abimes de perplexité.

Code :

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

1
2
3
4
5
6
 
enum Couleur { ROUGE , VERT, BLEU }
 
[...]
 
if (maCouleur < Couleur.VERT)

L'avantage de l'appel de compareTo() est que la méthode référence un ordre qui est etabli par ailleurs et que l'on peut retrouver.

[madmax13031978]

Bonjour à toutes et à tous,

Concernant le nouveau format d'énumération, je pense que celà peut -dans le cas de comparaisons numériques- s'avérer particulièrement intéressant. Maintenant, partant de là, s'il s'agit de comparer autre chose que des valeurs chiffrées, trés honnêtement, celà peut être sujet à confusion. La fonction "compareTo" est -à mes yeux- suffisament explicite et claire pour ne pas avoir à être changée ainsi. Du moins est-ce là une opinion "à chaud".
Maintenant, c'est à voir: sans doute cette apréhension est-elle purement synthétique, peut-être cette modification apporte-t'elle un réel plus? L'avenir le dira trés certainement...

[kisame]

Je suppose que si on autorise

Code :

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

1
2
3
4
5
 
if(CONSTANTE1 > CONSTANTE2)
{
 ...
}

il faut d'abord implémenter une fonction qui définisse le comportement? Ce que fait déjà le compareTo(). On est d'accord c'est une technique de renard sauvage pour faire entrer discrètement la surcharge d'opérateur (ce que moi j'aprécie beaucoup) par une brèche légèrement ouverte dans la forteresse imprenable

Ben alors pourquoi le limiter aux Enum ? On le fait bien une fois pour toute, ou on ne le fait pas. Je suis contre. Je préfère rien à un truc à moitié fait.

[fisico]

contre. d'accord avec xavlours. l'intérêt n'est pas très élevé loin de là

[gexian]

Totalement contre, parce que :
1 - comme dis plus haut, c'est la porte ouverte à la surcharge des opérateurs
2 - un enum n'est pas un numérique, ni une chaîne de caractères, c'est un enum, et rien d'autre. Donc l'implementation de comparable et comparator sont largement suffisant.

[Dog Eata]

Je suis entièrement d'accord avec nlegriel :
Il y a une grande différence entre pouvoir comparer deux valeurs d'une énumération grâce à l'opérateur < et introduire la surcharge des opérateurs dans Java.
Chaque valeur d'une énumération est unique et n'est jamais nulle, on utilise donc naturellement l'opérateur == pour les comparer. Pour les mêmes raisons ont peut effectuer un switch/case sur une énumération.
En plus il existe un ordre naturel sur n'importe quelle énumération qui est l'ordre dans lequel sont déclarées les modalités. L'utilisation de l'opérateur < n'est donc pas source d'erreur et personnellement je trouve qu'écrire :

Code :

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

Jour.MARDI < Jour.JEUDI

est plus parlant que d'écrire:

Code :

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

Jour.LUNDI.compareTo(Jour.JEUDI) < 0

Donc je vote pour.

[TheNOHDirector]

nlegriel a bien fait de rappeler le concept et la définition d'un enum. Révisez vos manuels.
Même si pour nombre d'entre vous une énumération peut être un ensemble de valeur non ordonnée (des exemples ont été cité) et qu'elle ne devrait pas être comparable, je répondrais que vous essayez d'imposer des limites techniques à l'enum par rapport au domaine dans lequel le type enum a été pensé.

Hors il faut bien le rappeler, quand une enum est construite le compilateur ajoute automatiquement un numéro ou un ordre pour chaque déclaration. il est donc normal du point de vue du langage, et plus généralement de la définition d'une énumération que les valeurs soient comparables entre elles.

La plupart d'entre vous ont divergé du sujet qui était bien de remplacer un appel à compareTo par un opérateur de comparaison. Ce n'est pas la même chose que d'argumenter si un enum est comparable. D'ailleurs si vous ne voulez pas que votre enum soit comparable par rapport au domaine métier parceque ça n'a pas de sens, alors il faut surcharger compareTo et lever par exemple l'exception UnsuportedOperationException. Il faut toujours penser à modéliser les objets du domaine métier en tenant compte des spécificités techniques du langage autrement il peut y avoir des surprises.

[fridobox]

Je pense que remplacer compareTo() par un opérateur rend la programmation moins orienté objet (c'est pour moi la clé de voûte du java).

Avec l'objet, on peut tout faire, même avec une Collection.

Si l'on dispose d'une Collection avec des éléments comparables :

Code :

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

1
2
3
4
5
6
7
Collection Size {
  S,
  M,
  L,
  XS,
  XL;
}

On ne peut surcharger compareTo() de Enum car elle est final.
Mais on peut très bien faire ses propres méthodes avec un nom explicite.
On passe un entier au constructeur de la collection afin de définir le rang :

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
17
18
19
20
21
22
23
24
25
26
Collection Size {
  S(-1),
  M(0),
  L(1),
  XS(-2),
  XL(2);
 
  public int iSize = 0;
 
  public Size(int iSize) {
    this.iSize = iSize;
  }
 
  public int compareToSize(Size s) {
    return iSize - s.iSize;
  }
 
  public boolean isGreaterThanSize(Size s) {
    return iSize > s.iSize;
  }
 
  public boolean isSmallerThanSize(Size s) {
    return iSize < s.iSize;
  }
 
}

On devrait même surcharger equals() pour comparer le rang.

L'utilisation est très explicite :

Code :

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

if (s1.isGreaterThanSize(s2)) System.out.println("vous êtes sûr que vous faites du 36?")