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

[pseudocode]

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: /* ... */
}

[nicorama]

Envoyé par kisame

Code :

Mauvaise fois inside

[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

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

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

[pseudocode]

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.

[kisame]

non mais je suis bien d'accord
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

[pseudocode]

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)) {}".

[adiGuba]

Envoyé par pseudocode

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

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

a++

[pseudocode]

Envoyé par adiGuba

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

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

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": /* ... */
  }
}

[kisame]

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

[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…

[natha]

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é.

[JeitEmgie]

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…)

[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

[OButterlin]

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)

[pseudocode]

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.

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

[OButterlin]

Envoyé par pseudocode

La classe Collator sert justement à ca.

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 "ß" ???

Ç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+

[pseudocode]

Envoyé par OButterlin

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

Ça m'intrigue

Code java :

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");

[adiGuba]

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...

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

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...

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

a++

[OButterlin]

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+

[adiGuba]

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++