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("") ) ?

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

Je ne dirais qu'une chose : ENFIN !

**romaintaz** · 19/12/2007, 11h01

D'accord et pas d'accord avec n!co.
Je ne vois pas trop pourquoi un switch sur les String serait plus crados qu'un enchaînement (lourd à digérer) de if - else...
Mais je suis super pour qu'on étende aussi les switches aux Enumérations !

J'aimerais bien pouvoir faire

Code :

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

1
2
3
4
5
6
7
8
 
switch (saison) {
    case SUMMER:
        ...
    case WINTER:
        ...
    ...
}

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

+1
Ce serait bien pratique.

**bassim** · 19/12/2007, 11h22

Envoyé par romaintaz

D'accord et pas d'accord avec n!co.
Je ne vois pas trop pourquoi un switch sur les String serait plus crados qu'un enchaînement (lourd à digérer) de if - else...
Mais je suis super pour qu'on étende aussi les switches aux Enumérations !

J'aimerais bien pouvoir faire

Code :

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

1
2
3
4
5
6
7
8
 
switch (saison) {
    case SUMMER:
        ...
    case WINTER:
        ...
    ...
}

Ca c'est deja faisable enums

c'est vrai qu'un switch avec des Strings peut être fait avec des enums !

**bobuse** · 19/12/2007, 11h46

Envoyé par romaintaz

D'accord et pas d'accord avec n!co.
Je ne vois pas trop pourquoi un switch sur les String serait plus crados qu'un enchaînement (lourd à digérer) de if - else...

En fait, si n!co pense bien comme moi, ce n'est pas que le switch serait plus crado que des if/then/else, mais que c'est le fait d'utiliser des String pour conditionner des actions qui est crado. Il vaut mieux effectivement utiliser des enums

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

**Hikage** · 19/12/2007, 12h45

Pour, ca permet de faire des switch a la place de if else à la chaine.

**bulbo** · 19/12/2007, 13h23

Contre,

Les enums apportent déjà cette possibilité, quand j'ai des constantes String je les déclare toujours en constante java (static final ou enum) ce qui évite les fautes de frappes accidentelles si je dois les utiliser a plusieurs endroits.

Quand au == entre string je vois pas trop ce que ça apporte de toute façon, il faudrait quand même que certains se fassent au fait que Java est objet.
S'il veulent de la surcharge d'opérateurs ils ont qu'a essayer C++, on les reverra vite parmi nous une fois qu'ils auront réalisé l'avantage de la chose et les multiples danger que ça introduit.

Bulbo

**bassim** · 19/12/2007, 15h19

J'ai voté pour,
mais si on utilisait les enums, le refactoring serait possible alors qu'avec cette solution très élégante ,non !

Hors sujet: pourquoi on débattrait pas des superpackages
il me semble que cette proposition est plus interressente que toutes les autres

**adiGuba** · 19/12/2007, 15h24

Envoyé par bassim

Hors sujet: pourquoi on débattrait pas des superpackages
il me semble que cette proposition est plus interressente que toutes les autres

Les superpackages sont déjà à un stade avancé et possède déjà leurs JSR... ils devraient donc bien faire partie de Java 7.

Ce n'est pas le cas de ces propositions

a++