Discussion :

[bulbo]

Sans vouloir retomber dans l'éternelle discussion java vs c++, juste pour te donner un autre éclairage:

En C++ si tu veux aller vite tu peux, les casts barbare, les accès pirate, les macros de brute, tout ça ce sont des 'raccourcis' que j'ai déjà pas mal vus dans les code C++ que j'ai rencontré dans mon travail. Heureusement C++ permet de faire aussi du travail propre comme tu le dis, mais pas seulement et seul la personne compétente et motivée le fera.

En Java tu n'as pas le choix, tu codes pur objet et en respectant les règles, le résultat est un code plus propre et pas forcément plus rapide à écrire. Ce qui donne l'impression que c'est un langage permettant d'écrire rapidement des programmes c'est qu'il vient avec une grosse API de base et qu'il y a énormément de framework puissant autour qui permettent de faire énormément de choses.

Quand tu regardes certains patterns par exemple, le java est vraiment plus lourd à manipuler, regarde le visiteur par exemple .. 10x plus simple en C++.

Moi actuellement j'utilise java pour un projet ou en lieu et place il y a une dizaine d'année tout le monde aurait mis du C++, pire je suis en train de me débarrasser des dernières parties écrites en C++ car en terme de maintenance et d'évolution elles sont vraiment pénalisantes pour le reste de notre projet.

Et c'est d'ailleurs pourquoi certains sucre syntaxique m'horripile autant..

En espérant ne pas démarrer un troll ici,

Bulbo

[LeGritche]

Je suis pour à 100% !

Je trouve "naturel" de faire des switchs sur des String.

[TPReal]

Pour, mais avant faire ce modification, il faut que ils finalement ajoutent l'operateur == pour String.

[Uther]

Ca par contre c'est impossible car même si String est un objet avec de caractéristiques spéciales(constantes, opération +, ...), il reste un objet et la comparaison entre objets signifie une comparaison de la référence.

Par contre je me demande s'il ne serait pas judicieux d'ajouter un type primitif string. C'est juste une idée comme, ça je n'ai pas plus que ça réfléchi aux éventuelles conséquences.

[TPReal]

Oui, un type primitif string peut etre une bonne idee - il y a un type string dans C# et ca marche parfaitement. Mais ce n'est pas un type vraiment primitif, et c'est pour ca qu'ils n'avons pas l'ajoute dans Java. Et ils ne l'ajouteront pas, probablement.
En general, je pense qu'il y a quelque chose sans tete avec toutes ces comparaisons:

Code :

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

1
2
3
5==5 => true, bien sur
new Integer(5)==5 => true
new Integer(5)==new Integer(5) => false

mais:

Code :

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

1
2
new Integer(5).equals(5) => true
new Integer(5).equals(new Integer(5)) => true

Avec ce savoir, on peut ecrire switch(new Integer(5)){case 5:...} et ca va marcher. Ca signifie que Java peut comparer references une fois, et valence une autre fois. Alors, maintenant je pense que c'est possible qu'ils ajoutent switch pour String sans changer comparaison des Strings.
(Excusez moi pour mon francais pauvre et pour mon manque d'accents, mais je ne suis pas francais. Merci.)

[Uther]

Non en fait c'est tout à fait logique. A partir du moment ou tu as une classe c'est une comparaison des références et non des valeurs.

Le cas de la comparaison Interger/int(et donc du switch) est particulier, d'ailleurs avant Java 1.4, ça te donnerait une erreur. C'est juste que grâce à l'autoboxing apparu avec Java 1.5, Integer est automatiquement converti en int. Donc la comparaison ce fait par valeur entre entre deux int.

[TPReal]

Il y a aussi un autre chemin pour faire comparaison des Strings possible. Je pense qu'ils pourraient changer de comparaison emploie quand on utilise switch. Maintenant le comparaison emploie par switch est ==, mais il pourrait etre .equals(). Ca ferait les deux codes faire la meme chose:

Code :

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

1
2
3
4
5
switch(obj1)
{
case obj2:
...
}

Code :

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

1
2
if(obj1.equals(obj2))
...

Avec ca, ils devrait permettre obj2 a ne pas etre const, et aussi ca aurait besoin de l'autoboxing du obj1 s'il est un type primitif. On de devrait changer l'ancien code, mais on peut comparer Strings et autres objets avec switch sans acun probleme.

[JHelp]

J'ai longtemps hésité entre pour et contre.
J'ai finalement voté pour. Apres tout pour des classes de tests ça me serait bien utile. Mais je penses pas l'utiliser des mes développements finaux. Enfin je dis ça mais au boulot on est encore à la java 1.4.2, ....
JHelp

[nicroman]

Perso je vote contre... les enumérations remplacent avantageusement ce genre d'opération.

Pour moi, du jour ou on fait un 'switch()' c'est qu'on a une liste de valeurs énumérées... et donc on utilise un enum.

Code java :

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

1
2
3
4
5
 
public enum Booleans {
    True,
    False
};

[pala00]

Contre aussi, il y a certainement des cas légitimes de faire de la comparaison de chaines en dur mais je reste convaincu qu'ils sont rares.

De façon générale les chaines de caractères ne devraient qu'exceptionnellement être dans le code. Si ce sont des éléments de langue 'Mr' 'Mme' 'Mlle' 'True' 'False': ils devraient être dans des fichiers de config pour anticiper la localisation ou permettre le parametrage par un non-développeur.

Les chaines de caractères ne devraient pas servir de marqueur interne, les énum sont là pour ça.
Reste les cas genre lecture de xml, communication diverses avec d'autres entités. Mais là encore on va vite se trouver avoir un niveau d'abstraction qui fera que les chaines à comparer ne seront pas statiques mais dans une variable.




Par contre le switch sur le chaines risque d'amener et d'encourager des pratiques peu recommandables:

-utilisation de chaines au lieu d'enum: c'est lourd et ca ne sert à rien.
-comparaison d'objet en passant par des strings:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
MonObjet obj=...;
swith(obj.toString()){
  case "toto":
    //
    break;
  case "titi";
 
 
}

ou pire

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
 
 
swith(obj.getClass()){
  case "MonObjet":
    //
    break;
  case "MonAutreObjet";
 
 
}

Je trouve le bénéfice-risque très limité.

[hamza_bba]

pour moi ça me faire qlq chose qui bien et donc je vote pour.

[corwin]

Contre car avec les enums je trouve cela plus propre et cela suffit a mon avis...

Ca c'est deja faisable enums

c'est vrai qu'un switch avec des Strings peut être fait avec des enums !

[gexian]

Dur de se prononcer sur cette proposition.

Le type String est très particulier, si je me souviens bien quand on fait :

Code :

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

1
2
3
4
String s1 = "Test";
String s2 = "Test";
System.out.println(s1.equals(s2));
System.out.println(s1 == s2);

on a le même objet dans la Heap (désolée, je ne connais pas la traduction) spécial String, donc les deux sont les même => le résultat est "true" pour equals et potentiellement pour ==.

Donc le type String est en effet approprié au switch.

Mais ça reste un Objet, et utiliser un objet dans les switch case, je suis totalement contre, les enum suffisent, java n'est pas php.

Vouloir intéresser du monde à java en laissant le développeur faire tout est n'importe quoi n'est pas une bonne idée, il suffit de voir le code php auquel on a affaire souvent. Je n'ai rien contre le php, mais les vrais développeur php sont rare, le php restant LE langage de bidouille pour ceux qui ne savent pas programmer. C'est bien, c'est utile, c'est un langage rapide, mais je doute que ce soit la finalité de java.

[OWickerman]

Clair, ça manque.

[deltree]

Dur de se prononcer sur cette proposition.

Le type String est très particulier, si je me souviens bien quand on fait :

Code :

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

1
2
3
4
String s1 = "Test";
String s2 = "Test";
System.out.println(s1.equals(s2));
System.out.println(s1 == s2);

on a le même objet dans la Heap (désolée, je ne connais pas la traduction) spécial String, donc les deux sont les même => le résultat est "true" pour equals et potentiellement pour ==.

Donc le type String est en effet approprié au switch.

Mais ça reste un Objet, et utiliser un objet dans les switch case, je suis totalement contre, les enum suffisent, java n'est pas php.

Attention c'est un cas particulier liée aux String compilées (les constantes), on peut éventuellement passer par un String.intern() si la String a été créée en cours de programme (saisie, transfert rmi...) pour obtenir le même résultat. Mais le mieux est en général d'utiliser un equals sur les String comme sur tous les objets.

Exemple, le code suivant est faux

Code :

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

1
2
3
4
5
6
7
8
 
System.out.println("Votre nom:")
String nom = lectureClavier();
if(nom=="bill"){
  // unreachable code
  System.exit(0);
}
//(mais je n'ai rien contre bill en particulier)

Je suis d'accord avec toi sur le fait qu'un switch ne doit à priori pas s'appliquer à des objets.

[lex2004]

Pour!

Cela sonnerait enfin le glas des longues séquences de if ... else if ... D'autre part, je serais même d'accord avec le fait que les opérateurs de comparaison soient surchargés pour String. Il y a en effet peu d'intérêt à comparer des chaînes de caractères par référence. Et le cas échéant Sun n'a qu'à proposer un nouveau moyen de comparer des objets en étant sûr que la comparaison se fasse par référence (un opérateur is ou une méthode statique Object.referenceEquals(Object, Object)). Pour finir, je dirais même (même si c'est un autre débat) qu'il serait temps que Sun réfléchisse à un moyen d'introduire la surcharge d'opérateurs dans Java. Je n'ai vraiment jamais perçu son omission comme un avantage (essayez de faire des calculs sur BigDecimal pour vous en convaincre).

[Dog Eata]

Faire un switch sur une chaine de caractère cela revient comparer cette chaine à un nombre fini de modalités existantes. En effet les expressions de case doivent correspondre à des expressions constantes.
Ces modalités seront donc soit :

• Écrites en dur dans le switch (dans le pire des cas)
• Déclarées comme constantes statiques ailleurs dans le code (dans le meilleur des cas)

Dans les deux cas il vaut mieux utiliser une énumération. Et ça tombe bien : on peut déjà faire un switch sur une énumération.
Donc je suis contre cette proposition et pour une utilisation plus fréquente des énumérations.

[Uther]

Dans les deux cas il vaut mieux utiliser une énumération. Et ça tombe bien : on peut déjà faire un switch sur une énumération.
Donc je suis contre cette proposition et pour une utilisation plus fréquente des énumérations.

Sauf que l'enum n'est pas exactement équivalent à une constante statique. D'ailleurs elles ne sont utilisées nulle part dans l'API Java. Pas même pour les classe post Java 5.0 il me semble.

[adiGuba]

Sauf que l'enum n'est pas exactement équivalent à une constante statique.

+1

Une enum représente un nombre d'élément fini.
Or on peut avoir besoin de faire un switch sur certain valeurs, et un cas générique pour toutes les autres valeurs... qui pourrait être infini !

Les enums ne sont pas vraiment adapté à cela !
De plus, je trouve que faire une enum uniquement pour simuler un switch sur les String est en quelque sorte un aveu que le switch sur les String est manquant

D'ailleurs elles ne sont utilisées nulle part dans l'API Java. Pas même pour les classe post Java 5.0 il me semble.

Elles sont bien utilisées dans Java 5.0/6 (Thread.State, Desktop.Action, TrayIcon.MessageType, ...) mais pas dans la grande majorité des classes mais c'est surtout pour une raison de compatibilité ascendante...

Contrairement aux Generics qui permettaient d'adapter les classes existantes en conservant la compatibilité, l'utilisation des Enums ne peut pas remplacer l'utilisation des constantes car cela casserait la compatibilité...


a++

[fridobox]

Cette évolution me semble inutile surtout parce qu'il n'est pas possible de l'utiliser en ignorant la casse ou avec trim() ou des expressions régulières.
L'étendre à toutes les classes est impensable.
L'utilisation des enums est bien suffisante est plus facile à faire évoluer.