Discussion :

[DranDane]

Contre...
- 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 ?)

Il me semble que non. Certaines opérations [comme par exemple le for (Personne Pers : _lPers)] ne fonctionnent que sur des objets de collections.

[JeitEmgie]

Et le switch est beaucoup plus lisible, je ne vois pas ce qui te dérange.
Dans ton exemple, ce n'est pas en passant par un tableau de char que tu auras une égalité entre "Strasse" et "Straße" pour autant.

Si encore on prenait en compte l'encodage mixe des caractères (ISO-8859-1 et UTF-8 par exemple) où effectivement il y a une différence entre 2 représentations du même mot, je comprendrais une quelconque réticence (même si dans tous les cas, les suites de "if" ne règleront pas le problème)

ce qui est dérangeant dans cette proposition est la distance qu'il y a entre la construction switch et un objet…

à la base, switch compare avec "==" pour choisir la branche…
mais pour String on supposerait utiliser equals() parce que c'est ce qui a un sens…
on passe donc d'une construction basée sur un opérateur intrinsèque à un appel de méthode…
ce n'est pas du même ordre et c'est gênant…
(ce qui n'est pas le cas d'un tableau de type char, int, … d'où l'idée de proposer l'extension du switch aux tableaux… et pas seulement de char… - et ce n'est évidemment pas pour régler le cas de Straße et Strasse…)

que l'on désire l'élégance du switch pour travailler avec des objets et en particulier ici des String est une chose, utiliser la même syntaxe en est une autre…

je préférerais voir une proposition qui offrirait une autre syntaxe pour les switch sur des objets et irait plus loin, dans le sens du "case" en Ruby par exemple, où l'on peut utiliser des regexp dans les conditions…

[OButterlin]

Je comprends le point de vue, mais bon, dans un switch, on ne voit nulle part l'opérateur qui a été utilisé pour le test...
Donc, pourquoi ne pas utiliser switch, au moins on se doute de ce qu'il fait.

[Thorna]

Ca fait franchement beaucoup de discussions pour pas grand chose...
Comme dans toutes les propositions de modification de syntaxe, on prend ou on ne prend pas...
Le switch existe plus ou moins dans cette forme ou dans une autre dans quasiment tous les langages et je ne pense pas que, pour cette raison, ces autres langages devienennt tout d'un coup moins bons.
C'est un moyen de simplifier des liste de if-else, mais ce n'est pas une raison pour en mettre 50 à la suite.
Pour parce que je ne vois pas pourquoi je serais contre... et parce qu'à chaque fois que j'ai dû m'en passer, ça m'a manqué!

[zais_ethael]

Cette question a probablement été déjà posée mais je n'ai pas le courage de me taper les 9 pages de posts :
pourquoi juste les strings? Pourquoi ne pas étendre le switch à tous les objet via la méthode equals()? Cela aurait même du être le mode de fonctionnement depuis le début puisque ça fonctionne aussi bien avec les types primitifs (depuis l'autoboxing, mais même avant rien n'empêchait un mode de fonctionnement différent si on désignait un type primitif, on programme pas en statiquement typé pour rien) qu'avec les strings, les dates, et de manière générale tout ce qu'on peut imaginer.
A la rigueur en y réfléchissant bien c'est peut-être même avec les strings que c'est le moins utile, car il existe plusieurs façons de les comparer (avec ou sans trim()? case sensitive ou insensitive? en ignorant les caractères accentués ou pas?). J'ai bien peur que même en disposant de ce switch on ne doive parfois se résoudre à faire un bon vieux if/else/if parce qu'on doit tuner la comparaison.

[zegreg]

je trouves que le switch case devrait être étendu à bcp plus qu'au String (Enumérations, ...). J'ai jamais compris pq c'était si limitatif..

[natha]

je trouves que le switch case devrait être étendu à bcp plus qu'au String (Enumérations, ...). J'ai jamais compris pq c'était si limitatif..

Le switch fonctionne déjà pour les enum. Ce qui est un argument pour dire que le switch sur les String est inutile car les enums y palient.

[zegreg]

Le switch fonctionne déjà pour les enum. Ce qui est un argument pour dire que le switch sur les String est inutile car les enums y palient.

il n'y a pas que les enums... pourquoi n'importe quel objet pourrait ne pas être evalué dans un switch case. Certains vont dire que c'est pas "joli", certes mais ca rend le switch case quasiment inutile (pour ma part je ne l'utilise jamais de fait cette énorme limitation).

Je suis pas un adepte des switch case, mais à certains moments ils serait bien pratiques pour remplacer des if else if assez longs... Et ce n'est pas toujours faisable de passer outre...

[scriptoff]

Apparement il y a de grande chance que ce soit implémenté , cf ici(90%)

[adiGuba]

il n'y a pas que les enums... pourquoi n'importe quel objet pourrait ne pas être evalué dans un switch case. Certains vont dire que c'est pas "joli", certes mais ca rend le switch case quasiment inutile (pour ma part je ne l'utilise jamais de fait cette énorme limitation).

J'en ai déjà parlé cela poserait problèmes pour plusieurs raisons :

• L'état d'un objet peut varier, et a.equals(b) peut être vrai à un moment donné et faux un peu plus tard si l'objet n'est pas immuable.
• L'appel à la méthode equals() peut nécessiter une synchronisation, car rien ne garantie qu'elle soit thread-safe.
• Le compilateur ne peut pas connaitre les valeurs des objets (puisqu'ils dépendent de l'exécution) et ne peut donc pas vérifier la cohérence du switch ni l'optimiser.

Tous ces problèmes ne sont pas vrai pour les Strings et les enums qui sont des objets bien spécifique (même si les enums ne sont pas totalement immuable, leurs conditions d'égalité ne peut pas être redéfini).

Je suis pas un adepte des switch case, mais à certains moments ils serait bien pratiques pour remplacer des if else if assez longs... Et ce n'est pas toujours faisable de passer outre...

Dans ce cas les enums serait plus adapté... ou alors il faut utiliser une Map !

a++

[vincevince]

Totalement pour... inutile de commenter...

[zegreg]

J'en ai déjà parlé cela poserait problèmes pour plusieurs raisons :

• L'état d'un objet peut varier, et a.equals(b) peut être vrai à un moment donné et faux un peu plus tard si l'objet n'est pas immuable.
• L'appel à la méthode equals() peut nécessiter une synchronisation, car rien ne garantie qu'elle soit thread-safe.
• Le compilateur ne peut pas connaitre les valeurs des objets (puisqu'ils dépendent de l'exécution) et ne peut donc pas vérifier la cohérence du switch ni l'optimiser.

Tous ces problèmes ne sont pas vrai pour les Strings et les enums qui sont des objets bien spécifique (même si les enums ne sont pas totalement immuable, leurs conditions d'égalité ne peut pas être redéfini).a++

1.Donc si je comprends bien je dois virer tous mes if/else if là je fait un a.equals(b) sous prétexte que mes objets varient... La synchro, faut la gérér là où il faut, c'est pas ton switch ou if / else if qui y changera quelque chose. Sinon selon ta théorie il ne faut surtout plus faire une test d'égalité à quelque niveau que ce soit ... switch ou if/else if

un code

Code :

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

1
2
3
4
5
 
if(a.equals(b)){
}
else if (a.equals(c)){
}

aurait les mêmes problèmes de ce que tu sites --> faut-il interdir les if pour autant. Ces pour ça qu'il existe les méthodes/blocs synchronisés, à toi de gérer...

2.je REdit, il n'y a pas que les strings ... ça pourrait. être intéressant dans d'autre cas

3.dernièrement puisqu'on part sur le sujet de la synchronisation qu'est-ce qui me garanti l'(in)égalité avec les numériques primitifs dans un switch en mulitthread? ou même avec une énumération ?

[pseudocode]

dernièrement puisqu'on part sur le sujet de la synchronisation qu'est-ce qui me garanti l'(in)égalité avec les numériques primitifs dans un switch en mulitthread? ou même avec une énumération ?

Je sais pas moi... L'immutabilité par exemple.

[A.SISSA]

sa sera bien pratique cool

[zegreg]

Je sais pas moi... L'immutabilité par exemple.

hmmm hmmm, oui les éléments d'une énum sont immutable... mais qu'est qui me fait dire que l'objet que je teste est toujours le même au sein de mon swich... même chose avec les primitifs

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
public class Main implements Runnable {
 
 
 
    private Color color;
 
    public Main(Color color){
        this.color = color;
    }
 
    public void setValeur(Color color){
        this.color = color;
    }
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws Exception {
        Main main = new Main(Color.BLUE);
        Thread th = new Thread(main);
        th.start();
        Thread.sleep(1000);
        main.setValeur(Color.RED);
 
    }
 
    public void run() {
 
        try{
            switch(color){
                case BLUE :
                    System.out.println("case 1");
                    System.out.println(color);
                    Thread.sleep(5000);
                    System.out.println(color);
                    break;
                 case RED :
                    System.out.println("case 2");
                    System.out.println(color);
                    Thread.sleep(5000);
                    System.out.println(color);
                    break;
 
            }
        }
        catch(Exception e){
 
        }
 
    }
 
    public enum Color{
        RED,BLUE,YELLOW;        
    }
 
}

Nous donnes

Code :

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

1
2
3
4
 
case 1
BLUE
RED

Résultat idem avec un int ou autre...

Donc les problèmes de synchro est un faux débat car elle doit être gérée avec les blocs/methodes synchro. Les blocs switch ne sont pas synchronisés...

[pseudocode]

hmmm hmmm, oui les éléments d'une énum sont immutable... mais qu'est qui me fait dire que l'objet que je teste est toujours le même au sein de mon swich... même chose avec les primitifs

Bien sur la variable d'entrée peut être modifiée a tout moment, mais c'est sa valeur au moment précis de l'évaluation de la fonction "switch(x)" qui fait foi.

ce qui doit être immutable ce sont les valeurs de comparaison (les "case" du switch) pour savoir quel bloc de code il faut executer. Sinon, le switch() ne serait pas l'équivalent de:

Code java :

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

1
2
3
4
5
6
7
8
 
if (variable.equals(case1)) {
  // ... case 1
} else if (variable.equals(case2)) {
  // ... case 2
} else {
  // ... default
}

mais plutot de:

Code java :

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

1
2
3
4
5
6
7
8
9
10
 
if (variable.equals(case1)) {
  // ...
}
if (variable.equals(case2)) {
  // ...
}
if (!variable.equals(case1) && !variable.equals(case2)) {
  // ...
}

[adiGuba]

hmmm hmmm, oui les éléments d'une énum sont immutable... qu'est qui me fait dire que l'objet que je teste l'est... et les int, long depuis quand c'est immutable?

Dans un switch tu ne peux utiliser que des constantes, et il est donc impossible de modifier leur valeur. Ainsi le code suivant est correct :

Code :

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

1
2
3
4
5
6
7
8
9
		final int A = 10;
		final int B = 20;
 
		// ...
 
		switch (x) {
		case A: System.out.println("A"); break;
		case B: System.out.println("B"); break;
		}

Tu peux faire tout ce que tu veux entre la déclaration des constantes et le switch tu ne pourras pas modifier leurs valeurs.


Avec des String on se retrouverait dans le même cas :

Code :

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

1
2
3
4
5
6
7
8
9
		final String A = "10";
		final String B = "20";
 
		// ...
 
		switch (x) {
		case A: System.out.println("A"); break;
		case B: System.out.println("B"); break;
		}

Il faut noter que les String sont déjà considéré à part par le compilateur/JVM et que c'est le seul "objet" que l'on peut utilisé comme constante (voir : Qu'est-ce qu'une constante ?).



Avec des object muable cela n'est plus vrai, par exemple avec des StringBuffer

Code :

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

1
2
3
4
5
6
7
8
9
		final StringBuffer A = new StringBuffer("10");
		final StringBuffer B = new StringBuffer("20");
 
		B.setCharAt(0, '1');
 
		switch (x) {
		case A: System.out.println("A"); break;
		case B: System.out.println("B"); break;
		}

On a modifié la valeur de B et le switch possède désormais deux cases identiques !



a++

[Suryavarman]

A voté "Pour", car les langages comme Java/.Net/Delphi sont fait pour développer rapidement et de façon un peu crado.

[bulbo]

Pour les langages comme Java/.Net/Delphi sont fait pour développer rapidement et de façon un peu crado.

Amusant comme remarque .. java fait pour programmer crado, surprenant quand on voit le soin apporté dés la conception du langage à éviter les choses potentiellement dangereuses découverte avec d'autres langages comme le C++

Etonnant aussi quand on voit le nombre d'API matures et efficace qui ont vues le jour en Java et qui commence à être portée vers d'autres langages.

Juste pour ma culture personnelle, pour toi quel serait le ou les langages destinés à programmer proprement et efficacement ?

Bulbo

[Suryavarman]

Je voulais dire que ces langages sont plutôt fait pour coder rapidement. Fatalement le code est un moins réfléchi. Le c++ si tu t'amuse à coder aussi vite que java ou autres, bein ton code sera pas très jolie. Je passe 7h par jour sur du delphi, ( oui oui ici on parle java ) et 5h par jour sur du c++ ( pour moi c++ permet de faire des oeuvres d'art performante c'est mon avi . ) Mais c'est pour dire que quand on choisi du c++ c'est qu'on a le temps de réfléchir à ce qu'on fait, si on prend du java, delphi ou .Net c'est pour allé vite. Mais ne remettons pas la discution java c++ ici.

Juste que un peu de sucre syntaxique ça aidera à coder plus vite. Et que si c'est moins jolie bein c'est pas trop grave .

EDIT: J'ai corrigé un peu mon msg plus haut, c'est qu'il tombait un peu comme un cheveux sur la soupe :p. ( si j'ai sorti le mot crado c'était en référence aux messages du début du sujet ).