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

Citation:

---

Envoyé par adiGuba

Mais que ce soit pour les String ou les enums la reflection permet de changer les données d'une instance, donc le problème est le même en fait...

---

Heu... non. Changer les données dans une instance d'enum ne modifie pas la fonction rendue par le switch:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

MyEnum somevalue = MyEnum.VALUE1;   // (...) somevalue.internalvalue = 1.23456; // (...)   switch (somevalue) { case VALUE1: System.out.println("VALUE1"); break; case VALUE2: System.out.println("VALUE2"); break; default: System.out.println("don't know"); break; }

---

Citation:

---

Envoyé par pseudocode

Heu... non. Changer les données dans une instance d'enum ne modifie pas la fonction rendue par le switch:

---

C'est tout simplement parce que tu modifies un champs qui n'est pas utilisé pour identifier l'enum. Si tu modifies les champs name ou ordinal tu obtiendras bien des résultats incorrects...

Par exemple le switch est basé sur l'ordinal de l'enum, et avec cette méthode doEvil() tu as VALUE1 qui vaut VALUE2 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class Surprise {   enum MonEnum { VALUE1, VALUE2; }   public static void main(String[] args) throws Exception { doEvil(); switch (MonEnum.VALUE1) { case VALUE1: System.out.println("VALUE1"); break; case VALUE2: System.out.println("VALUE2"); break; default: System.out.println("don't know"); break; }   }   static void doEvil() throws Exception { java.lang.reflect.Field field = Enum.class.getDeclaredField("ordinal"); field.setAccessible(true); field.set(MonEnum.VALUE1, 1); // ordinal passe de 0 à 1 } }

---

Mais bon le problème ne vient pas de String ou Enum mais d'une mauvaise utilisation de la réflection...


a++

Citation:

---

Envoyé par adiGuba

C'est tout simplement parce que tu modifies un champs qui n'est pas utilisé pour identifier l'enum. Si tu modifies les champs name ou ordinal tu obtiendras bien des résultats incorrects...

---

Ah, oui. Désolé. :oops:. J'avais pas pensé a modifier "ordinal". :aie: Bon cela dit c'est vrai que tout ca n'a pas trop de rapport avec la discussion actuelle.

Au fait, est-ce qu'il sera possible de sortir les "constantes" du switch ?

Code:

---

1 2 3 4 5 6 7 8 9

final String YES = "Yes"; final String NO = "No";   switch(s) { case YES: break; case NO: break; default: break; }

---

Ca paraitrait logique, vu que c'est le cas pour les int, char,...

En tout cas si ce n'est pas le cas ça serait génant.

Citation:

---

Envoyé par pseudocode

Bon cela dit c'est vrai que tout ca n'a pas trop de rapport avec la discussion actuelle.

---

Oui c'est vrai on a un peu (beaucoup) dévié... :oops:

Citation:

---

Envoyé par Uther

Ca paraitrait logique, vu que c'est le cas pour les autre types.

---

+1

En fait cela dépend. Par exemple avec le code suivant :

Code:

---

final String YES = "Yes";

---

:arrow: YES est bien une constante et lorsqu'on l'utilise le compilateur effectue en fait un remplacement de valeur...


Par contre si tu a :

Code:

---

final String YES = maMethodeQuiRenvoiYes();

---

:arrow: YES n'est pas une constante car elle ne peut pas être connu à la compilation, et ne pourra donc pas être remplacé par le compilateur.
Dans ce cas elle ne pourra pas non plus être utilisé dans un swith...


Plus d'info sur les constantes dans la FAQ : Qu'est-ce qu'une constante ?


a++

Bonsoir,

Je pense pas cette fonctionnalité va révolutionner le monde même si j'ai voté "pour".

Pour avoir le "==" suffit d'appeler la méthode "intern".

Je me demandais plutôt, si via une surcharge de l'opérateur "==" ou la méthode "equals" (pour rester dans "java" et non c++), on peut appeler switch sur Object.


Cordialement.

j'ai voté pour, c'est tres utile!
merci:yaisse2:

Contre. Je ne vois pas l'intérêt.

Les switch pour moi ne servent que pour les enums (et avec les entiers, car avant les enums n'existaient pas).
Ça permet de parcourir différents cas, par exemple, comme vu précédemment :

Code:

---

1 2 3 4 5 6 7

public void handleSeason(Season season) { switch(season) { case SUMMER: ... case WINTER: ... default: ... } }

---

Cette proposition inciterait les gens à tout écrire en String plutôt qu'à imposer statiquement un ensemble de valeurs.
Déjà que ça se fait déjà, et je trouve ça très moche, ça donnerait ça:

Code:

---

1 2 3 4 5 6

public void handleSeason(String season) { switch(season) { case "summer": ... case "winter": ... default: ... }

---

La différence avec le cas précédent, c'est que le contenu de la variable season est vérifié à la compilation dans le premier cas et n'est même pas vérifié dans le 2e cas (si season vaut "winmer", la compilation ne plante pas).

Sans parler des problèmes de charset, de equalsIgnoreCase, etc...

J'ai voté contre,

Je préfère garder la syntaxe if else pour les comparaisons d'objet et les switch case pour les enumérations (cela oblige la personne à faire des énumérations et évite les problèmes de "magic number" déjà trop récurent).

Pour cette proposition.

D'abord, je suis d'accord avec Uther et les autes intervenant qui ont préciser que le type String est un type tout a fait particuleir du langage Java. Les arguments contre cette proposition en raison du caractère Objet du langage ne me paraisse pas opportun dans ce cas, a moins que l'on souhaite remettre en question le statut si bizzare de String (ce qui est un autre débat, ... )

Par contre, l'argument de pseudocode résume assez bien ma perplexité

Citation:

---

A mon sens un switch() s'utilise avec une liste de valeurs fixes et connues "a priori" => une liste de constante => un Enum.

---

Ce type de modification rend possible des codes du type

Code:

---

1 2 3 4 5 6 7 8 9 10

Stirng s = "AAA" ; switch(s) { case "AAA": s = "BBB"; case "BBB": s = "CCC"; default: throw new IllegalArgumentException(s); }

---

Sans que cela soit choquant, cela perturbe ma marote personnelle qui concerne l'importance extrème que j'accord à la lisbilité du code.

Donc, quand cela sera adopté, je ferais tout pour que, dans les standards de codage que nous utilisons, la String utilisée dans un Switch ne soit modifé dans ce même switch!

Citation:

---

Envoyé par Bollagain

Donc, quand cela sera adopté, je ferais tout pour que, dans les standards de codage que nous utilisons, la String utilisée dans un Switch ne soit modifé dans ce même switch!

---

Ils pourraient tout aussi bien forcer l'utilisation d'une String finale

Code:

---

final String s = "AAA";

---

Sinon faire une erreur de compi.

Je ne comprend pas trop cet argument !?

La même chose est possible avec les switch numérique :

Code:

---

1 2 3 4 5 6 7 8 9

int i = 0; switch(i) { case 0: i = 1; case 1: i = 2; default: throw new IllegalArgumentException(s); }

---

On ne peut pas interdire une structure seulement car cela permet de faire quelque chose de pas très propre... sinon c'est la fin des langages de programmation :aie:


Par contre au niveau des case c'est sûr qu'il faudra obligatoirement une constante...

a++

Citation:

---

On ne peut pas interdire une structure seulement car cela permet de faire quelque chose de pas très propre... sinon c'est la fin des langages de programmation

---

L'arguement est trés juste...

Ma remarque me parait d'ailleurs allé plus dans le sens de quelques bonnes pratiques et n'est pas pertinante pour rejeté la proposition.

Par contre, pour ce qui concerne les valeurs dans le switch, et il prévu que les valeurs du switch soit final ???

Citation:

---

Envoyé par Bollagain

Par contre, pour ce qui concerne les valeurs dans le switch, et il prévu que les valeurs du switch soit final ???

---

Il devrait y avoir les mêmes règles que pour les numériques, donc oui...

Pour rappel les valeur des cases doivent être des constantes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

int i = 0; int variable = 1; final int CONSTANTE = 2;   switch(i) { case 0: // OK c'est une constante break; case CONSTANTE: // OK : C'est une constante break; case variable: // ERREUR : case expressions must constant expressions break; }

---

a++

Citation:

---

Envoyé par bassim

Ca c'est deja faisable enums

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

---

FYP

Citation:

---

Envoyé par vbrabant

Que pensez-vous de ce cas ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

static boolean booleanFromString(String s) { switch(s) { case "true": case "yes": case "y": case "1": return true; case "false": case "no": case "n": case "0": return false; default: throw new IllegalArgumentException(s); } }

---

Vincent

---

Bon, j'ai écrit une phrase au-dessus, et me voià avec un argument massue en faveur des switchs de String.
Finalement c'est un peu le même problème qu'avec les JSP où tout passe par les chaines. Dans un contexte métier, utilisons les enums. Dans certains cas, il faut éviter la prolifération de Classes, ou d'Enum. Maintenant, je pense que ton enum NonOui.java pourra être vite rentabilisé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public Enum NonOui{ NON(0), OUI(1), JESAISPAS(2);   public static Enum getValue(String s){ if (s.equals("o")||s.equals("oui")) return OUI; else return NON;   }   }

---

Citation:

---

On ne peut pas interdire une structure seulement car cela permet de faire quelque chose de pas très propre... sinon c'est la fin des langages de programmation

---

Pour (pour les mêmes raisons des personnes qui sont pour), puis contre (pour les mêmes raisons des personnes qui sont contre :mrgreen:), puis l'argument de adibuga m'a décidé : pour.

Il est tout à fait possible de faire du code ultracrado avec n'importe quoi.

Les arguments comme quoi on dirait, que faire directement avec un string sans passer par un enum est crade... on pourrait très facilement les retourner contre absolument tous les autres types primitifs du langages qui sont autorisés dans le switch.

je ne vois pas en quoi un

Code:

---

1 2 3 4 5 6 7 8 9

switch { case 2: // blabla break;   default : //blibli }

---

est plus propre que

Code:

---

1 2 3 4 5 6 7 8 9

switch { case "toto": // blabla break;   default : //blibli }

---

Pas vraiment de moins. Un léger plus. Pour

Citation:

---

Envoyé par kisame

je ne vois pas en quoi un (...) est plus propre que (...)

---

A mon sens, le switch est plus propre avec un "enum" car on peut detecter les typos lors de la compilation:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

enum ANSWER { YES, NO; } switch (answer) { case YES: /* ...*/ case NOz: /* ...*/ <---- NOz cannot be resolved or is not a field } switch (answer) { case "YES": /* ...*/ case "NOz": /* ...*/ }

---

Citation:

---

Envoyé par pseudocode

A mon sens, le switch est plus propre avec un "enum" car on peut detecter les typos lors de la compilation:

---

On peut toujours avoir un problème de typo avec des numériques... Faut-il pour autant interdire les switch sur les numériques ?


Attention que ce soit bien clair je ne dis pas que les enum sont une mauvaise solution ! Bien au contraire...

Car en plus de la vérification à la compilation on peut également utilisé l'option -Xlint:fallthrough (ou -Xlint tout court) du compilateur javac pour obtenir un warning lorsqu'un switch sur une enum ne comporte pas toutes les valeurs de l'enum. Pratique car cela permet d'éviter d'oublier une valeur (cela se configure également sur les EDI).


Concrètement dans le cas YES/NO une enum est intéressante car la liste des valeurs est fini, et que l'enum peut apporter pas mal de chose.


Toutefois dans bien des cas on n'a pas forcément besoin d'un tel niveau de vérification, et surtout lorsque le besoin est unique à une méthode, ce qui fait que l'enum perd beaucoup de son intérêt.



Un switch sur des String est à la fois très lisible et rapide à coder.
De plus cela permet d'utiliser des chaines "exotiques" (comprendre : qui contient des caractères non-autorisés dans le nom d'un attribut).


a++

ouais mais là ça reste de la faute de frappe.

de la même manière

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

switch { case 1: break; case 2: break; case 3: break; case 44: <--- ça passe alors que c'est une faute de frappe. break; case 5: break; }

---

ça reste aussi porc et dangereux avec un type primitif.

Sinon oui bien évidement pour le control de type et tout le reste. L'enum reste la meilleure solution je suis d'accord. Je dis juste que je trouve pas ça con d'autoriser les string autant que les types primitifs.