JDK 7: Proposition 4 : possibilité d'utiliser les String dans les switch case -> Intégrée

Version imprimable

Voir 40 message(s) de cette discussion en une page

Citation:

Envoyé par kisame

ouais mais là ça reste de la faute de frappe.

de la même manière (...)

ça reste aussi porc et dangereux avec un type primitif.

Oui, bien sur il n'y a pas de solutions miracles, mais c'est plus difficile à repérer dans les chaînes de caractères...
Code:

1 2 3 4 5 6 7 8 9 switch (role) { case "guest": /* ... */ case "user": /* ... */ case "poweruser": /* ... */ case "manager": /* ... */ case "administator": /* ... */ case "noaccess": /* ... */ default: /* ... */ }

15/02/2008, 14h39
nicorama
Citation:
Envoyé par kisame

Code:

1 2 case 44: <--- ça passe alors que c'est une faute de frappe.
Mauvaise fois inside :yaisse2:
15/02/2008, 15h00
kisame

oui totalement.

Mais pas plus que
case "administator":
case "NOz": /* ...*/
C'est un exemple basé sur une erreur de frappe en réponse à un exemple basé sur une erreur de frappe. Ne me dis pas le contraire :D

c'était ce que je voulais montrer :) (la mauvaise foi) mais c'est pas moi qui l'ai dit :mrgreen:

edit : tiens ... en quoi mon exemple est pire que le sien ;) ?
15/02/2008, 15h15
pseudocode

Citation:

Envoyé par kisame

edit : tiens ... en quoi mon exemple est pire que le sien ;) ?

En théorie les 2 erreurs de frappes sont équiprobables. Dans la réalité, il est plus courant de se gourer sur une suite de lettres que sur une suite de chiffres.

Reprend tous les posts de la discussion et compte le nombre de fautes/typos sur des lettres versus des chiffres. ;)
15/02/2008, 15h39
kisame

non mais je suis bien d'accord :D
C'est juste que pour moi, la faute de frappe n'est pas un argument de poids. Pour cette proposition c'est un argument mais à prendre pour ce que c'est. Et oui ça arrive plus souvent de se planter dans une chaine de caractère que dans la saisie d'un chiffre :)

Ton exemple venait quand on discutait sur la "propreté" du code. Dans les deux cas ça reste autant dégueu.

Encore une fois, une constante résout le problème (là je pense qu'il ne peut même pas y avoir débat sur ce point). Mais le problème existe autant pour les types primitifs que pour les string. C'est ce que je voulais dire.

Je suis pour un utilisation décomplexée des strings :)
15/02/2008, 16h00
pseudocode

Citation:

Envoyé par kisame

Je suis pour un utilisation décomplexée des strings :)

Pour avoir mis les mains dans des appli AJAX, l'utilisation a outrance des chaînes de caractères m'a laissé un goût amer. C'est certe tres rapide et puissant, mais à debuguer/maintenir c'est une horreur.

Si le switch(String) est possible dans Java 7, j'ajouterai une nouvelle "bonne pratique" dans mon guide de developpement: Ne pas l'utiliser, sauf dans dés cas très simples pour eviter une suite de "if ("XX".equals(s)) {}".
15/02/2008, 16h02
adiGuba

Citation:

Envoyé par pseudocode

sauf pour simplifier une suite de "if ("XX".equals(s)) {}".

Ben... C'est justement l'objectif du switch(String) :koi:

a++
15/02/2008, 16h09
pseudocode
Citation:

Envoyé par adiGuba

Ben... C'est justement l'objectif du switch(String) :koi:

Oui, je m'en suis apperçu en l'écrivant. :aie:

Ce que je veux dire c'est de ne pas utiliser le switch(String) comme un design pattern (a la javascript).
Code:

1 2 3 4 5 6 7 8 9 // THAT'S BAD void persist(String command, Object o) { switch(command) { case "create": /* ... */ case "update": /* ... */ case "delete": /* ... */ } }
15/02/2008, 16h58
kisame

Citation:

Je suis pour un utilisation décomplexée des strings

heu ... c'était plus une phrase à double sens :)

et puis ça veut dire ne pas avoir peur des les utiliser quand c'est fait de manière intelligente. Ca ne veut pas dire faire nimp :)
16/02/2008, 13h05
JeitEmgie

contre

l'égalité stricte de String est une problématique trop subtile pour baser une construction controlant le flux d'exécution de programmes là-dessus…
16/02/2008, 14h18
natha

Citation:

Envoyé par JeitEmgie

l'égalité stricte de String est une problématique trop subtile pour baser une construction controlant le flux d'exécution de programmes là-dessus…

Ce serait au compilateur de gérer ça correctement de toute façon en faisant un appel "mastring".equals(var) plutôt qu'un ==, ça doit pas être bien compliqué.
16/02/2008, 14h33
JeitEmgie

Citation:

Envoyé par natha

Ce serait au compilateur de gérer ça correctement de toute façon en faisant un appel "mastring".equals(var) plutôt qu'un ==, ça doit pas être bien compliqué.

ce n'est pas ça le propos…

la distance entre les niveaux sémantiques du "switch" et de la "String" sont trop grands pour les mélanger…

à la limite un "switch" sur un "char []" serait acceptable de ce point de vue…
mais pas une String…

(Strasse == Straße et autres joyeusetés…)
07/03/2008, 12h22
ant_ams

Je suis pour.

J'irais même un peu plus loin en proposant le switch pour les objets.
Voir mon blog pour plus de détail (en anglais)
http://www.jroller.com/agoubard/entry/switch_on_objects

Anthony
07/03/2008, 14h37
OButterlin
Citation:

Envoyé par JeitEmgie

ce n'est pas ça le propos…

la distance entre les niveaux sémantiques du "switch" et de la "String" sont trop grands pour les mélanger…

à la limite un "switch" sur un "char []" serait acceptable de ce point de vue…
mais pas une String…

(Strasse == Straße et autres joyeusetés…)

Je pense qu'il n'y a pas de différence entre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 switch (varString) { case "printemps" : ... case "été" : ... case "automne" : ... case "hiver" : ... }
et
Code:

1 2 3 4 5 6 7 8 9 10 11 if ( varString.equals("printemps") ) { ... } else if ( varString.equals("été") ) { ... } else if ( ... ) ...etc
Et le switch est beaucoup plus lisible, je ne vois pas ce qui te dérange.
Dans ton exemple, ce n'est pas en passant par un tableau de char que tu auras une égalité entre "Strasse" et "Straße" pour autant.

Si encore on prenait en compte l'encodage mixe des caractères (ISO-8859-1 et UTF-8 par exemple) où effectivement il y a une différence entre 2 représentations du même mot, je comprendrais une quelconque réticence (même si dans tous les cas, les suites de "if" ne règleront pas le problème)
07/03/2008, 14h50
pseudocode

Citation:

Envoyé par OButterlin

Dans ton exemple, ce n'est pas en passant par un tableau de char que tu auras une égalité entre "Strasse" et "Straße" pour autant.

La classe Collator sert justement à ca. :P

Si le switch(String) utilise "String.equals()" c'est moins puissant que faire un "if Collator.compare()"
07/03/2008, 14h56
OButterlin

Citation:

Envoyé par pseudocode

La classe Collator sert justement à ca. :P

Si le switch(String) utilise "String.equals()" c'est moins puissant que faire un "if Collator.compare()"

Tu veux dire que la classe Collator ne distingue aucune différence entre 2 caractères "ss" et un "ß" ??? 8O

Ça m'intrigue, je ferai un test à l'occasion (d'ailleurs merci en passant, je ne connaissais pas Collator, ça résoudra pas mal de choses... ;))

A+

Citation:

Envoyé par OButterlin

Tu veux dire que la classe Collator ne distingue aucune différence entre 2 caractères "ss" et un "ß" ??? 8O

Ça m'intrigue
Code:

1 2 3 4 5 6 Collator collator = Collator.getInstance(Locale.FRENCH); collator.setStrength(Collator.PRIMARY); if (collator.compare("Straße", "Strasse")==0) System.out.println("Tout pareil");

07/03/2008, 15h13
adiGuba
Citation:

Envoyé par ant_ams

J'irais même un peu plus loin en proposant le switch pour les objets.

Cela pose quand même certains problèmes :
- De synchronisation : les objets pourraient bien être modifié depuis un autre thread.
- D'immuabilité : les objets ne sont pas forcément immuable et leurs valeurs peut bien changer pendant qu'on est dans le switch :?
- De validité du code : le compilateur ne peut pas comparer les différentes valeurs des objets, et on peut donc se retrouver avec plusieurs case qui sont en réalité identique, par exemple :
  Code:
  
  1 2 3 4 5 6 7 8 9 10 11 12 BigDecimal d1 = new BigDecimal(1); BigDecimal d2 = new BigDecimal("1"); switch(value) { case d1: // ... break; case d2: // ... break; }
De plus cela empêche le compilateur d'effectuer les optimisations habituelles... :?

Bref un switch case sur des objets "standards" je ne suis pas trop pour...

Citation:

Envoyé par OButterlin

Je pense qu'il n'y a pas de différence entre :

Si il peut y en avoir une : pour les int le switch utilise un espèce de table de hashage pour améliorer les performances. On peut raisonnablement penser que ce serait la même chose pour les String...

Mais je te l'accorde dans 99% des cas la différence avec des if/else ne sera pas flagrante ;)

Citation:

Envoyé par OButterlin

Ça m'intrigue, je ferai un test à l'occasion (d'ailleurs merci en passant, je ne connaissais pas Collator, ça résoudra pas mal de choses... ;))

Les Collators permettent de comparer des chaines de caractères avec des règles plus souples qu'une simple comparaison "binaire", et permet ainsi de prendre en compte certaines spécificités des locales...

:faq: Comment comparer des chaînes de caractères selon la Locale ?

a++
07/03/2008, 15h21
OButterlin

Citation:

Envoyé par pseudocode

Code java :

Collator collator = Collator.getInstance(Locale.FRENCH);
collator.setStrength(Collator.PRIMARY);

if (collator.compare("Straße", "Strasse")==0)
    System.out.println("Tout pareil");

Effectivement, j'ai testé, même si ça m'étonne, ça marche, c'est identique pour lui...

Merci
A+
07/03/2008, 16h28
adiGuba
Citation:

Envoyé par OButterlin

Effectivement, j'ai testé, même si ça m'étonne, ça marche, c'est identique pour lui...

ß dérive de ss donc c'est normal qu'il trouve que c'est la même chose. C'est comme le œ et le oe de la langue française :
Code:

1 2 3 4 5 Collator collator = Collator.getInstance(Locale.FRENCH); collator.setStrength(Collator.SECONDARY); if (collator.compare("oeil", "œil")==0) System.out.println("Tout pareil");
Le Collator en mode SECONDARY ou moins ignore ce type de différence ;)

a++

Voir 40 message(s) de cette discussion en une page