Discussion :

[natha]

Euh moi je le ferai pas avec un == ce switch, l'appel du equals() fait très bien l'affaire, et ainsi ca serait généralisé aux objets et non plus aux Strings.
De plus ca ne se remplace pas toujours par des enum, par exemple une entrée utilisateur qui est une String on pourrait faire
switch (val)
{
case "val1":faire un truc;break;
case "val2":faire un truc;break;
...
default : entréeinvalide;break;
}
Si on a un enum il faut déjà retrouver a quelle valeur de l'enum correspond la String

Ah bon ?

Code :

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

1
2
3
4
5
6
7
8
9
try {
    Enum valEnum = Enum.valueOf(val);
    switch (valEnum) {
        case valEnum1: faire un truc; break;
        case valEnum2: faire un truc; break;
    }
} catch (IllegalArgumentException e) {
    // entree invalide
}

[pierreact]

Je l'utilise beaucoup en ruby (pas rails)...
C'est tres c'est tres bon CEPENDANT Il faut faire attention aux programmeurs novices qui peuvent utiliser ca n'importe comment....
Je pense que si c'est accepter, il faudra mettre des regles claires d'utilisation dans un environnement d'entreprise pour ne pas se retrouver avec un code "crado" comme certains ont dit...

Je suis assez mitige sur le point mais me laisse quand meme voter pour...
Je n'ai jamais eu de vrai probleme sur d'autres languages avec ca...

[covao]

Pas contre

Je n'ai pas encore utilisé la méthode hashCode de la classe String. En attendant, je pense utiliser cette méthode

[djo.mos]

Pour.
Et je ne voies vraiment pas d'inconvénients à ça ...

[Uther]

Pour également la classe string est depuis le début une classe très particulière donc faire une exception de plus pour son cas ne me parait pas genant.

[yostane]

Si ça apporte en plus les optimisations du switch je suis pour

[jshadocks]

Je suis totalement pour un switch sur String, bien plus lisible qu'une série de if-else imbriqués. Le switch sur Enum de Java 5 ne permet pas de traiter tous les besoins. On peut souhaiter tester des radicaux de comptes comptables par exemple, sans que ceux-ci soient pour autant définis dans un Enum. Cela ne me parait pas crado. Quant à étendre le principe à tous les objets, je n'en mesure ni l'intérêt, ni les conséquences.

[toomsounet]

Je suis pour aussi il est temps de rattrapper le Cobol sur ce point !! Pour plus de clarté dans le code.

[Patriarch24]

Il y a plein de points soulevés ici surper intéressants :
* les switchs d'intervalle : pourquoi pas, ça allège les suites de case sans fin...
* les switchs de String : là je suis moins pour ; je ne vois pas de cas où on ne peut les remplacer par autre chose (enum, introspection, injection de dépendances, fichier de conf, autres ?...)
* les switchs généralisés : là par contre, je suis entièrement contre. Si ça amuse certains de faire des switchs en pagaille, autant faire du C.

Donc je vote contre.

[ripounet]

Je serais même partisan de créer un nouveau mot-clé à cet effet, avec les particularités suivantes par rapport au switch:
- se base sur equals, valable pour tout type d'objet non primitif
- les alternatives sont mutuellement exclusives, et ou laisse tomber la nécessité du break (d'inspiration GOTO)

Note: pour ceux que ça intéresse, la structure de contrôle "cond" en Scheme est vachement mieux pensé que le switch C-like.

[FranT]

Moi, je vote pour. C'est une fonction qui m'a toujours manquée et qui sera utile à plus d'un.

[azalsup]

Cette proposition constituera une avancé pour le langage java.

Honetement avec un langage aussi dynamique pourquoi se limier aux entiers lors des structures switch

Vive la pythonisation du java

[pseudocode]

contre.

L'utilisation du type String dans un switch() devrait renvoyer une erreur: "Apprenez a utiliser les enums."

[hedes]

Oui, entièrement contre.
Cette discussion et le sondage sont intéressants : elle montre que beaucoup de gens préférent coder rapidement sans se soucier de la maintenance...

[kenji_getpowered]

Moi je vote pour

une question :

Cette discussion et le sondage sont intéressants : elle montre que beaucoup de gens préférent coder rapidement sans se soucier de la maintenance...

En quoi cela affecterait la maintenance?

[pseudocode]

En quoi cela affecterait la maintenance?

Typiquement une combo-box avec { "M", "Mme", "Mlle" } et le switch() qui va avec. Si tu traduis l'IHM de ton application, tu dois également traduire le code du switch() (et ne pas te tromper en recopiant ).

Avec un Enum le problème disparait. Tu garde le meme code du switch() et tu as juste a traduire le toString() de l'Enum.

[Uther]

Bah oui c'est un expemple de mauvaise utilisation mais bon, si tu veux interdire avec switch, la personne fera la même chose avec une série de if, ce qui tout aussi bête.

Si tu veux interdire tout ce qui peux potentielement être mal utilisé, autant interdire le Java.

[foued_scorpion]

ça fait longtemps que j'attend cette possibilité et voilà enfin on va la trouver.
ç'était le bordel avec plusieurs "if".

[pseudocode]

Bah oui c'est un expemple de mauvaise utilisation mais bon, si tu veux interdire avec switch, la personne fera la même chose avec une série de if, ce qui tout aussi bête.

A l'inverse, autoriser le switch(String) revient a "valider" cette mauvaise pratique de codage: "Si ca existe c'est que c'est permis".

A mon sens un switch() s'utilise avec une liste de valeurs fixes et connues "a priori" => une liste de constante => un Enum.

[natha]

"Si ca existe c'est que c'est permis".

C'est très réducteur...
Un bon langage de programmation est obligé de permettre des choses crades pour pouvoir être qualifié de langage permissif et puissant.
Ce n'est pas parce qu'on peut faire ("toto" == str) que c'est une bonne pratique (et que ça devrais être permis).
Ce n'est pas parce qu'on peut nommer une variable ($ma_variablePourrieQuiEstNomméeComme_la_super_classe) que c'est une bonne pratique (et que ça devrais être permis).
Ce n'est pas parce qu'on peut coder une classe complète sur une seule ligne que c'est une bonne pratique.
etc.

Le switch de String est un manque à cause de certains aspects particuliers des API Java et de l'historique du langage. L'introduire comblerait un manque mais il est clair que c'est aux programmeurs de se responsabiliser un minimum.
Je trouve cet ajout bien moins problématique que les alias. Un Switch de String, même crados, restera lisible et facilement corrigeable.