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

[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

[natha]

Envoyé par vbrabant

Que pensez-vous de ce cas ?

Je dirais que c'est un excellent exemple pratique démontrant l'utilité dans certains cas de figure du switch de String.
On pourrait bien sûr faire une enum mais pour quel gain ??

[djo.mos]

Bonjour.
Je vois que l'argument de l'enum revient sans cesse pour descridéter cette proposition, et c'est logique en un sens.
Mais il faut se mettre à l'esprit que ce n'est pas toujours possible de passer par un enum, ou d'avoir un enum.
Par exemple, avec l'exemple de Vincent, le s qu'on teste peut être une valeur entré par l'utilisateur dans une IHM quelconque, peut aussi parvenir du parsing d'un fichier, des données récupérés d'une socket, etc. etc. etc. J'aimerais bien voir comment on peut utiliser les enums dans ces cas ...
Autre cas de figure: lorsque les éventualités sont un peu trop nombreuses pour qu'on prenne la peine de les coder sous forme d'enums ... perso, je ne m'amuserais pas à le faire avec plus d'une douzaine de valeurs possibles

[natha]

Envoyé par djo.mos

J'aimerais bien voir comment on peut utiliser les enums dans ces cas ...

Techniquement parlant c'est très simple, cf cet exemple :

http://www.developpez.net/forums/sho...8&postcount=41

Le #valueOf a ses limites par contre car si on souhaite tester une saisie qui ne respecte pas les normes de nommage des variables java comme par exemple : "pèse-personne" (le tiret '-' n'est pas accepté, l'accent est déconseillé), ou "un avion" (l'espace pose problème), ça va doubler le travail de création de l'enum.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
enum MonEnum {
 
    PESE_PERSONNE("pèse-personne"),
    UN_AVION("un avion");
 
    String str;
    private MonEnum(String str) {
        this.str = str;
    }
 
    public static MonEnum valueFor(String str) {
        for (MonEnum me : values()) {
            if (me.str.equals(str)) {
                return me;
            }
        }
        return null;
    }
}

Ca devient vraiment pénible et je comprendrais qu'on préfère coder une succession de if/else plutôt que se taper l'enum.

[djo.mos]

Voilou ! le valueOf est limité et ne permettrait certainement pas de faire la même chose que l'exemple de Vincent.

[pseudocode]

Envoyé par natha

Je dirais que c'est un excellent exemple pratique démontrant l'utilité dans certains cas de figure du switch de String.
On pourrait bien sûr faire une enum mais pour quel gain ??

on pourrait surtout le faire avec des Listes...

Code java :

1
2
3
4
5
6
7
8
static List<String> trueEntries  = Arrays.asList("true","yes","y","1");
static List<String> falseEntries = Arrays.asList("false","no","n","0");
 
static boolean booleanFromString(String s) {
	if (trueEntries.contains(s)) return true;
	if (falseEntries.contains(s)) return false;
	throw new IllegalArgumentException(s);
}

[natha]

Envoyé par pseudocode

on pourrait surtout le faire avec des Listes...

C'est juste, bien vu !
Mais ça vaut pour les cas où plusieurs propositions provoquent le même résultat.

[pseudocode]

Envoyé par natha

C'est juste, bien vu !
Mais ça vaut pour les cas où plusieurs propositions provoquent le même résultat.

A mon avis le "switch(string)" n'est pas une solution à un problème fonctionnel.

Si vous avez des dizaines de "if (s.equals("xxxx"))" à la suite les uns des autres, la solution à votre probleme ce trouve plus dans un changement de "conception" qu'un changement de "syntaxe".

[Uther]

on pourrait surtout le faire avec des Listes...

Dans ce cas précis oui, mais ca reste une solution de contournement pour un problème particulier.
On perd une propriété essentielle du switch: travailler sur des constantes, de plus, le passage par une liste complique inutilement une opération triviale.
Je sais que l'optimisation n'est généralement pas la priorité des développeurs JAVA, mais ca ne fait jamais de mal.

[pseudocode]

On perd une propriété essentielle du switch: travailler sur des constantes

DAns ce cas il faudrait etendre le switch() a tous les objets immutable (BigInteger, ...). Mais comment reconnaitre un immutable en Java ? (sachant qu'on peut modifier une String par reflection).

Envoyé par Uther

Dans ce cas précis oui, mais ca reste une solution de contournement pour un problème particulier.
(...)
Je sais que l'optimisation n'est généralement pas la priorité des développeurs JAVA, mais ca ne fait jamais de mal.

Je ne sais pas comment sera implémenté le switch(string), mais battre une recherche dans un HashSet() ca va etre dur.

[adiGuba]

Envoyé par pseudocode

DAns ce cas il faudrait etendre le switch() a tous les objets immutable (BigInteger, ...). Mais comment reconnaitre un immutable en Java ? (sachant qu'on peut modifier une String par reflection).

Les String ont quand même un status particulier puisqu'il peuvent être défini en tant que constante, ce qui n'est pas le cas des autres types d'objets...

Envoyé par pseudocode

Je ne sais pas comment sera implémenté le switch(string), mais battre une recherche dans un HashSet() ca va etre dur.

Cela pourrait intégrer une sorte de hashset directement dans le bytecode...
D'ailleurs il me semble que c'est déjà fait ainsi pour les switch standard !


a++

[Uther]

Envoyé par pseudocode

DAns ce cas il faudrait etendre le switch() a tous les objets immutable (BigInteger, ...). Mais comment reconnaitre un immutable en Java ? (sachant qu'on peut modifier une String par reflection).

Je ne parlais pas détendre à tous les immutables mais juste aux Strings constants, ce qui ne devrait pas poser de problèmes vu qu'ils posèdent déjà un traitement particulier en JAVA ou ils sont "inline" de la même manière que les types de base.

Après si tu modifies un String par réflexion(je ne savais pas que la réflexion authorisait ce genre de chose), c'est un détournement de l'usage normal de JAVA. Celui qui fait ça, a quand même quelques connaissances et sait qu'il faut s'attendre au pire vu que:

• Le but d'une classe Immuable, c'est justement d'empecher ça.
• les Strings(et particulièrement les constants) ont droit à des traitements bien particuliers.

Je serais bien curieux de voir ce que ca donne de modifier un String constant par réflexion, ca doit réserver quelques surprises.

[pseudocode]

Envoyé par Uther

Je serais bien curieux de voir ce que ca donne de modifier un String constant par réflexion, ca doit réserver quelques surprises.

effectivement:

http://www.developpez.net/forums/sho...&postcount=720

[Uther]

En effet c'est bien le genre de surprise auquel je pensais, et il doit y en avoir bien d'autres.

C'est bizarre j'aurais cru naivement que la réflexion sur des éléments inaccessibles levait une exception. C'est quand même un sacré trou dans l'encapsulation! Même si ca me plait de savoir que l'on peut briser quelque règles de temps en temps.

[adiGuba]

Envoyé par Uther

C'est bizarre j'aurais cru naivement que la réflexion sur des éléments inaccessibles levait une exception. C'est quand même un sacré trou dans l'encapsulation! Même si ca me plait de savoir que l'on peut briser quelque règles de temps en temps.

On ne peut pas tout avoir : une réflection puissante sans aucun "risque"...

A noter quand même que cela impose l'utilisation de setAccessible() ET que cela pourrait être bloqué par un SecurityManager...

a++

[pseudocode]

Envoyé par Uther

C'est bizarre j'aurais cru naivement que la réflexion sur des éléments inaccessibles levait une exception.

c'est configurable: on en parle dans le reste de la discussion...

C'est quand même un sacré trou dans l'encapsulation! Même si ca me plait de savoir que l'on peut briser quelque règles de temps en temps.

Ce n'est pas un trou. Pour moi "Immuable" n'est pas synonyme de "attribut privé". C'est pour ca que je suis contre un switch() sur la valeur d'un litteral String (qui n'est pas immuable) mais je suis pour un switch() sur la reference d'une instance d'un enum (qui est immuable).

[adiGuba]

Envoyé par pseudocode

Ce n'est pas un trou. Pour moi "Immuable" n'est pas synonyme de "attribut privé". C'est pour ca que je suis contre un switch() sur la valeur d'un litteral String (qui n'est pas immuable) mais je suis pour un switch() sur la reference d'une instance d'un enum (qui est immuable).

Il est possible de casser n'importe quelle objet ou règle d'immuabilité avec
La réflection et setAccessible(true)... et même les enums (après tout il s'agit ni plus ni moins d'un objet) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Surprise {
 
	enum MonEnum {
		AAA, BBB;
	}
 
	public static void main(String[] args) throws Exception {
 
		System.out.println(MonEnum.AAA);
		doEvil();
		System.out.println(MonEnum.AAA);
 
	}
 
	static void doEvil() throws Exception {
		java.lang.reflect.Field field = Enum.class.getDeclaredField("name");
		field.setAccessible(true);
		field.set(MonEnum.AAA, "CCC");
	}
}

Mais l'utilisation de setAccessible() est vraiment très limité et pas très propre lorsque c'est fait n'importe comment...


a++

[pseudocode]

Envoyé par adiGuba

Il est possible de casser n'importe quelle objet ou règle d'immuabilité avec La réflection et setAccessible(true)... et même les enums (après tout il s'agit ni plus ni moins d'un objet) :

Peut-on peut modifier la valeur de la reference (internal address) d'une instance ?

Je pensais que le switch(enum) utilisait la "reference" de l'instance , mais peut-etre me trompe-je.

[adiGuba]

Envoyé par pseudocode

Peut-on peut modifier la valeur de la reference (internal address) d'une instance ?

Non...

Envoyé par pseudocode

Je pensais que le switch(enum) utilisait la "reference" de l'instance , mais peut-etre me trompe-je.

C'est vrai.

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

a++

[Uther]

Envoyé par adiGuba

On ne peut pas tout avoir : une réflection puissante sans aucun "risque"...

A noter quand même que cela impose l'utilisation de setAccessible() ET que cela pourrait être bloqué par un SecurityManager...

a++

Ok je viens de rejeter un coup d'oeil dans la doc en ce qui concerne la réflexion et elle est bien protégée comme il me semblait m'en souvenir. Ce qui m'avait échappé, c'est que cette protection pouvait être levée par le setAccessible(true).
Donc c'est en effet une bonne chose: on est parfaitement conscient de ce que l'on fait quand on décide d'enfreindre les règles.

Cela me renforce d'autant plus dans l'idée que celui qui utilise setAccessible(true), particulièrement pour modifier des champs non documentés, sait à quoi il s'expose. On n'a pas a se poser de question pour lui. De toule façon avec la réflexion sans contrôle, on est suceptible de faire les pires saloperies possibles avec les String, le cas du switch n'étant qu'un problème parmi d'autres.