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

[n!co]

Envoyé par bobuse

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

C'est bien à cela que je pensais => soit un element de plus a maintenir pour être sur que si tu change un string a un endroit, faut pas oublier de le modifier de l'autre.

Ce qui aujourd'hui est élégament réglé avec les énums ...

[nicorama]

Envoyé par n!co

C'est bien à cela que je pensais => soit un element de plus a maintenir pour être sur que si tu change un string a un endroit, faut pas oublier de le modifier de l'autre.

Ce qui aujourd'hui est élégament réglé avec les énums ...

Je renchéris : le Java, ce n'est pas du PHP. Je vote contre !

Par contre, pourquoi ne fait-on pas un switch d'objet ? Pour quelques algorythmes complexes, je renvois soit un Integer, soit un Objet complexe. Un switch basé sur les références est 100% entretenable en refactoring, non ?

[DrHelmut]

Contre...

Car bien que ça parte d'une bonne intention au départ, cela implique des complications inutiles car d'autres pratiques équivalentes (et pas plus lourdes - genre Enum) existent. 3 ans que je code en java en m'en passant très bien perso...

Les complications inutiles que j'y voit :

- Implémenter switch/case avec des String mais pas avec tous les objets ne serait ABSOLUMENT PAS dans la philosophie objet (de java en tout cas)
En effet pourquoi une opération fonctionnertait avec UN type d'objet et pas avec les autres ? Ce serait une première ! (non ?)

- Avec les IDE, simplifier la syntaxe de Java ne servira pas à grand chose je pense et ça alourdirait ou impliquerait des modifications plus ou moins significatives de la JVM pour un gain très peu significatif.

- Un NullPointerException potentiel...

[benwit]

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]

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 :

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.

[Deadpool]

Envoyé par DrHelmut

Contre...

Car bien que ça parte d'une bonne intention au départ, cela implique des complications inutiles car d'autres pratiques équivalentes (et pas plus lourdes - genre Enum) existent. 3 ans que je code en java en m'en passant très bien perso...

Les complications inutiles que j'y voit :

- Implémenter switch/case avec des String mais pas avec tous les objets ne serait ABSOLUMENT PAS dans la philosophie objet (de java en tout cas)
En effet pourquoi une opération fonctionnertait avec UN type d'objet et pas avec les autres ? Ce serait une première ! (non ?)

Non ce n'est pas une première, l'opérateur + est surchargé pour les String (opérateur de concaténation) et pas pour les autres objets.

Sinon perso, ayant fait du C# et considérant le fait que le switch sur les String est possible en C#, je suis plutôt pour avoir la même chosee en Java.

[adiGuba]

Envoyé par Deadpool

Non ce n'est pas une première, l'opérateur + est surchargé pour les String (opérateur de concaténation) et pas pour les autres objets.

L'opérateur + est surchargé pour tous les objets... mais il génère une String

Mais les String sont quand même des objets bien particulier, il possède leurs propre littéral et pas mal de spécificité par rapport aux autres objets. En particulier ils peuvent être utilisé comme constante (et donc déterminé à la compilation).

Ce qui permettrait de les utiliser dans un switch, contrairement aux objets standards car le compilateur ne pourrait pas vérifier leurs valeurs et les éventuelles problèmes que cela pourrait poser (doublons, etc...).



Et un switch est quand même bien plus pratique qu'un suite de if/else ou qu'un grosse Map d'association...



En parlant des switch j'aimerais bien également avoir la possibilité d'utiliser un interval de données avec les types numériques, par exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
switch(intValue) {
    case 0-9:
           ...
           break;
    case 10-99:
           ...
           break;
    default:
           ...
           break;
}

Actuellement on est obligé d'utiliser un case par valeur


a++

[OButterlin]

Envoyé par adiGuba

Code :

Oui, ça serait pas mal du tout...

[Deadpool]

Envoyé par adiGuba

L'opérateur + est surchargé pour tous les objets... mais il génère une String

C'est pas faux.

Non en fait je voulais dire que par exemple on pouvait faire ça :

Code :

1
2
3
4
 
String a = "toto";
String b = "tata";
String c = a + b;

mais pas ça :

Code :

1
2
3
4
5
6
 
BigInteger i = BigInteger.valueOf(1);
BigInteger j = BigInteger.valueOf(2);
BigInteger k = i + j;
//ne compile pas
//Erreur :The operator + is undefined for the argument types java.math.BigInteger, java.math.BigInteger.

Mais c'est vrai que c'était pas clair.


En java 5 ça marche quand même avec les types wrappers du fait de l'auto-(un)boxing.

[bmoussaud]

Trop longtemps que j'attend cette fonctionnalité

[longbeach]

je suis complètement pour.

[Alec6]

On peut pas pousser plus loin le langage ?

Avec les primitifs on compare à la fois l'égalité et l'identité

Avec les strings on compare le concept d'égalité.

On devrait pouvoir faire cette comparaison avec tout type d'objet.

Et mieux

switch equality{ } pour un equals

switch identity{ } pour un ==

[natha]

Envoyé par Alec6

On peut pas pousser plus loin le langage ?

C'est dangereux de vouloir trop en faire.
Je ne vois pas vraiment de besoin pour les autres types d'objets.

[ReaM]

Comme dit par plusieurs d'entre vous , je suis pour parce que c'est clair que dans certains cas ( ils ne sont pas nombreux non plus ) cette possibilité m'a énormément manqué, mais il faut quand même ne pas oublier que les enums ont souvent palier à ce problème.

[cysboy]

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

[xavlours]

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

[zefyre]

Le switch avec des Strings simpifiera la vie des développeurs dans de nombreux cas:
1-Dans les factory on pourra faire un switch sur le nom de la classe
2-Dans les MVC switch sur les actions

Les if-else sont mort, vive les siwtch !!

[adiGuba]

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

[benwit]

Envoyé par zefyre

Le switch avec des Strings simpifiera la vie des développeurs dans de nombreux cas:
1-Dans les factory on pourra faire un switch sur le nom de la classe
2-Dans les MVC switch sur les actions

Les if-else sont mort, vive les siwtch !!

Je suis pour le switch des String dans certains cas mais absolument contre pour les exemples que tu donnes.

Personnellement, je pense que les utiliser dans ces cas font du mauvais code
à moins que j'ai mal compris ou que des exemples concrets me soient montré.

Pourquoi faire un switch dans les factory ? Pour choisir une implémentation particulière ? Mieux vaut à mon avis faire une injection de dépendance (via Spring ou autre, un simple fichier de paramétrage par exemple) ou bien un tableau de String avec une constante pour l'indice.

Pour ce qui est du switch sur les actions, ce n'est pas mieux !!!
Cela me rappelle une blague d'un prof sur les menus :
Un développeur débutant fait un test de l'item du menu pour déclencher l'action appropriée.
Un développeur de chez Microsoft fait une étude statistique pour mettre en haut du menu (et tester en premier) les items qui ont le plus de chance d'être executé.
Un développeur de C++ fait un tableau de pointeur de fonctions.

En tant que développeur Java, je code des objets actions avec une méthode execute qui fait directement mon traitement sans faire une suite de tests (switch ou pas ...)

[kpouer]

Euh moi je le ferai pas avec un == ce switch, l'appel du equals() fait très bien l'affaire, et ainsi ca serait généralisé aux objets et non plus aux Strings.
De plus ca ne se remplace pas toujours par des enum, par exemple une entrée utilisateur qui est une String on pourrait faire
switch (val)
{
case "val1":faire un truc;break;
case "val2":faire un truc;break;
...
default : entréeinvalide;break;
}
Si on a un enum il faut déjà retrouver a quelle valeur de l'enum correspond la String