Netbeans account : nico@share.java.net
Merci de ne pas poser de questions techniques par MP
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 ?
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...
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
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 :
Pour maîtriser totalement le type. Mais c'est un peu lourdingue.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 set(monEnum.name()) MonEnum.valueOf(get())
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.
Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
De la bonne manière de poser une question (et de répondre).
Je ne fais pas de service par MP. Merci (...de lire les règles...).
Ma page dvp.com
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.
-"Tout ça me paraît très mal organisé. Je veux déposer une réclamation. Je paye mes impôts, après tout!"
-"JE SUIS LA MORT, PAS LES IMPÔTS! MOI, JE N'ARRIVE QU'UNE FOIS".
Pieds d'argile (1996), Terry Pratchett 1948 - 2015
(trad. Patrick Couton)
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 :
Actuellement on est obligé d'utiliser un case par valeur
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 switch(intValue) { case 0-9: ... break; case 10-99: ... break; default: ... break; }
a++
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
C'est pas faux.
Non en fait je voulais dire que par exemple on pouvait faire ça :
mais pas ça :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 String a = "toto"; String b = "tata"; String c = a + b;
Mais c'est vrai que c'était pas clair.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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.
En java 5 ça marche quand même avec les types wrappers du fait de l'auto-(un)boxing.
-"Tout ça me paraît très mal organisé. Je veux déposer une réclamation. Je paye mes impôts, après tout!"
-"JE SUIS LA MORT, PAS LES IMPÔTS! MOI, JE N'ARRIVE QU'UNE FOIS".
Pieds d'argile (1996), Terry Pratchett 1948 - 2015
(trad. Patrick Couton)
Trop longtemps que j'attend cette fonctionnalité
Benoit Moussaud - XebiaLabs - Automatisation des déploiements. Screencast & Demo
je suis complètement pour.
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 ==
Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
De la bonne manière de poser une question (et de répondre).
Je ne fais pas de service par MP. Merci (...de lire les règles...).
Ma page dvp.com
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.
Je suis pour aussi à 200%.
Cà manquait vraiment et c' est très pratique !
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 ==.
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 !!
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++
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 ...)
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager