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

**vbrabant** · 16/12/2007, 20h26

Aujourd'hui :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
static boolean booleanFromString(String s) {
    if (s.equals("true")) {
        return true;
    } else if (s.equals("false")) {
        return false;
    } else {
        throw new IllegalArgumentException(s);
    }
}

Demain :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
static boolean booleanFromString(String s) {
    switch(s) {
      case "true":
        return true;
      case "false":
        return false;
      default:
        throw new IllegalArgumentException(s);
    }
}

**gronono** · 19/12/2007, 02h00

Bonjour,

Voila une nouveauté qui serait vraiment utile.

Je suis à 100% pour.

Fini les if, else if, if à rallonge. Les cases apportent beaucoup de clarté au code. Donc il est + maintenable.

A+
Gronono

**yann2** · 19/12/2007, 02h04

Bonsoir

J'ai voté pour mais j'ai quand même une petite question. Est ce que cette fonctionnalité inclue le fait de pouvoir comparer les chaines avec l'opérateur == en toute tranquillité ?

Merci

[edit]
du coup ça me fait penser à une autre fonctionnalité qui peut être cool:
utiliser les opérateurs <, >, <=, >= (pas le == évidemment) sur des objets de type Comparable appelle automatiquement la méthode compareTo... je suis trop gourmand ? Il faudrait voir si cette question n'est pas mieux dans la proposition 3.
[/edit]

Yann

**Napalm51** · 19/12/2007, 09h12

Pour à 200%, j'ai toujours trouvé que le switch sur String était un manque dans de nombreux langages.

**metalpetsFR** · 19/12/2007, 09h24

J'ai voté pour, mais finalement apres reflexion cela ne serait plus cohérent par rapport a l'opérateur == comme disait "yann2".
Cela reviendrais a dire que le type String est un type primitif.

Plutot contre en faite (mince je lui premier)

**adiGuba** · 19/12/2007, 09h56

Envoyé par metalpetsFR

Cela reviendrais a dire que le type String est un type primitif.

String est quand même un type bien particulier

a++

**zulot** · 19/12/2007, 10h04

Je ne vois pas en quoi le case changerais le s.equals(string) !!!

En tout cas je suis pour à 100%, je trouve que c'est un manque dans certain cas.

**n!co** · 19/12/2007, 10h07

Moi je ne suis pas pour !

C'est pratique quand tu fais du php, mais en java ca fait grado.
Vu que les string seront de toute facon en dur dans les cases, il est plus préférable de porter l'utilisation des Enumérations dans ce cas.

**bobuse** · 19/12/2007, 10h54

Je trouve ça effectivement joli et séduisant. mais comme dit n!co, un switch de String reste de toutes façons crado.
Et vu qu'il a beaucoup de propositions de sucre syntaxique, je ne veux pas qu'il y en ait trop, au risque de compliquer le langage.

**romaintaz** · 19/12/2007, 10h59

Je suis pour, je trouve que ça peut simplifier le code, sans mettre trop de complexité...

Quant au fait de pouvoir utiliser le switch en utilisant le ==, je ne sais pas trop comment cela se matérialiserait du point de vue écriture du code java...
A ce niveau là, aussi pourquoi ne pas proposer une comparaison des Strings en ignorant la casse (en gros, que l'on puisse utiliser le equalsIgnoreCase("") au lieu de equals("") ) ?

**elitost** · 19/12/2007, 11h07

+1
Ce serait bien pratique.

**coyote999** · 19/12/2007, 12h25

Je suis pour mais je serais d'avis de ne pas seulement se limiter au type String. Pourquoi ne pas aller plus loin et permettre un switch qui pourrait comparer des objets identiques.

On pourrait comparer des String, des BigDecimals mais également des classes que nous avons développé nous-mêmes.

**benwit** · 20/12/2007, 08h15

Je suis d'une même avis que coyote.

Envoyé par coyote999

Je suis pour mais je serais d'avis de ne pas seulement se limiter au type String. Pourquoi ne pas aller plus loin et permettre un switch qui pourrait comparer des objets identiques.

On pourrait comparer des String, des BigDecimals mais également des classes que nous avons développé nous-mêmes.

**natha** · 20/12/2007, 09h17

Les String sont souvent utilisées un peu partout comme clés (ActionCommand, Layout, etc.).
Apporter un switch se révèlera très intéressant pour tous ces endroits où il faut soit faire des if/else, soit créer une enum et faire des astuces style :

Code :

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

1
2
set(monEnum.name())
MonEnum.valueOf(get())

Pour maîtriser totalement le type. Mais c'est un peu lourdingue.

Alors oui pour le switch sur String.

Contre le switch généralisé car créer une instance d'un objet par case juste pour comparer, ça va pas me plaire du tout

Comme l'a dit adiGuba je crois, le type String est un type particulier entre le primitif et l'objet normal.

**cysboy** · 20/12/2007, 14h01

Je suis pour aussi à 200%.
Cà manquait vraiment et c' est très pratique !

**xavlours** · 20/12/2007, 14h02

Je suis pour, principalement parce que les Strings sont historiquement utilisés comme clé/constante dans pas mal de coins de l'API. Par contre je trouve que ça ne suffit pas, il faudrait généraliser ça, parce qu'il est mieux d'avoir une règle qu'une exception, et l'étendre sur tous les Objets avec la méthode equals. Libre au développeur de surcharger cette méthode pour utiliser l'égalité pointeur ==.

**adiGuba** · 20/12/2007, 15h23

Envoyé par xavlours

Par contre je trouve que ça ne suffit pas, il faudrait généraliser ça, parce qu'il est mieux d'avoir une règle qu'une exception, et l'étendre sur tous les Objets avec la méthode equals. Libre au développeur de surcharger cette méthode pour utiliser l'égalité pointeur ==.

Si cela serait généralisé sur tout les objets on aurait encore plus d'exception, avec :

D'un coté le switch sur les types primitifs et les String, qui utiliserait des constantes vérifié par le compilateur et dont le résultat sera toujours le même pour une valeur donné, et surement optimisé par le compilateur (car connaissant les valeurs des case, il peut les ordonner).
De l'autre coté le switch sur les objets, basé sur le couple hashCode()/equals(), avec des objets dont la valeur est inconnu à la compilation, et dont la valeur pourrait varier au court du temps...

Perso si je suis plutôt pour le switch sur les String, je ne suis pas d'accord pour le généraliser à tous les objets...

a++

**covao** · 21/12/2007, 11h15

Pas contre

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

**pseudocode** · 29/12/2007, 02h12

contre.

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

**hedes** · 03/01/2008, 11h45

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