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

**pseudocode** · 15/02/2008, 14h02

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 :

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

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** · 15/02/2008, 14h39

Envoyé par kisame

Code :

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

1
2
 
case 44:    <--- ça passe alors que c'est une faute de frappe.

Mauvaise fois inside

**kisame** · 15/02/2008, 15h00

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** · 15/02/2008, 15h15

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** · 15/02/2008, 15h39

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** · 15/02/2008, 16h00

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** · 15/02/2008, 16h02

Envoyé par pseudocode

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

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

a++

**pseudocode** · 15/02/2008, 16h09

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 :

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

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** · 15/02/2008, 16h58

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** · 16/02/2008, 13h05

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** · 16/02/2008, 14h18

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** · 16/02/2008, 14h33

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** · 07/03/2008, 12h22

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** · 07/03/2008, 14h37

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 :

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

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

et

Code :

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

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** · 07/03/2008, 14h50

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** · 07/03/2008, 14h56

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** · 07/03/2008, 15h00

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 :

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

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** · 07/03/2008, 15h13

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 :

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

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** · 07/03/2008, 15h21

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** · 07/03/2008, 16h28

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 :

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

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