JDK 7: Proposition 6 : Invocations chainées [Débat]

**bobuse** · 19/12/2007, 16h42

Envoyé par bassim

comme ceci donc :

Code :

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

1
2
3
4
5
Thing thing = new Builder()
    .try{setSomething(something)}
catch (e: Exception) { ...}
    .setOther(other)
    .result();

c'est carrément illisible

D'où tu sors ton ".try" ?? Je sais pas si ça existe dans le langage, mais si oui, alors c'est ça qui rend illisible ton exemple !!

**bassim** · 19/12/2007, 16h45

Envoyé par bobuse

D'où tu sors ton ".try" ?? Je sais pas si ça existe dans le langage, mais si oui, alors c'est ça qui rend illisible ton exemple !!

en fait, je voulais relever le cas ou on voudrait gérer une exception qui serait générée par une des méthodes, c'est tout

mais bon ça peut se faire en utilisant l'ancienne méthode !

**bobuse** · 19/12/2007, 16h46

Envoyé par bassim

en java ça serait:

Code :

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

1
2
3
4
5
with monObjet {
setSomething();
setChose();
traitement(getChose());
}

qu'en pensez vous ?

Bof. L'intérêt du chaînage est de faire tenir sur une ligne quelques appels de méthodes qui ne retournent rien.
Là, on reste avec un beau pavé, autant garder la syntaxe d'aujourd'hui par rapport à cette solution.

**bobuse** · 19/12/2007, 16h47

En fait, comme dans d'autres proposition, il faut essayer (et c'est parfois dur pour moi aussi) de ne pas penser à ce que ça pourrait permettre de pire mais de bien peser le pour et le contre.

Car sinon, on n'aurait jamais eu l'opérateur ternaire "? :" en Java !!!

**bulbo** · 19/12/2007, 16h55

Envoyé par bobuse

En fait, comme dans d'autres proposition, il faut essayer (et c'est parfois dur pour moi aussi) de ne pas penser à ce que ça pourrait permettre de pire mais de bien peser le pour et le contre.

Car sinon, on n'aurait jamais eu l'opérateur ternaire "? :" en Java !!!

Opérateur que je n'utilise quasi jamais et seulement dans des cas particuliers

le ? c'est très bien mais pour avoir du maintenir du code écrit ainsi, il est si facile de passer a cote de code écrit en 2eme partie de ligne, genre après un ; ou un if :

Code :

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

1
2
 
if (null != bidule) doUnTruc();

Bulbo

**romaintaz** · 19/12/2007, 17h05

Envoyé par bassim

en fait, je voulais relever le cas ou on voudrait gérer une exception qui serait générée par une des méthodes, c'est tout

mais bon ça peut se faire en utilisant l'ancienne méthode !

Dans le langage actuel, tu serais obligé de faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
try {
    monObject.doSomething();
} catch (...) {
    ...
}
try {
    monObject.doAnotherThing();
} catch (...) {
    ...
}
...

Donc niveau lisibilité, ça aussi c'est pas terrible

**Jester** · 19/12/2007, 17h12

Contre,

return this; si on veut pouvoir le faire.

**OButterlin** · 19/12/2007, 17h12

En l'occurrence, si on veut comparer le code "pascal", ça se ferait comme ça en java

Code :

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

1
2
3
4
 
monObjet.maMethode1();
monObjet.maMethode2();
monObjet.maMethode3();

le "with" ne traite pas les exceptions levées par l'une des méthodes, donc, si maMethode1() plante, tu ne risques pas de faire la suivante...

**bassim** · 19/12/2007, 17h14

Code :

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

1
2
3
4
5
6
7
8
9
10
try {
    monObject.doSomething();
} catch (...) {
    ...
}
try {
    monObject.doAnotherThing();
} catch (...) {
    ...
}

dans ce cas, j'aurais crée un type d'exception pour chaque méthode: Exception1 et Exception2

Code :

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

1
2
3
4
5
6
try {
    monObject.doSomething();
    monObject.doAnotherThing();
} catch (Exception1 ex) {    }
catch (Exception2 ex2) {    }
}

**adiGuba** · 19/12/2007, 17h16

Il y a une différence entre les deux codes :

Dans le premiers les deux méthodes sont appelées quoi qu'il arrive
Dans le second la seconde méthode n'est appelé que si la première n'a pas remonté d'exception...

A noter quand même qu'il est assez rare qu'on "ignore" une exception comme dans le premier exemple...

a++

**bobuse** · 19/12/2007, 17h18

Envoyé par OButterlin

En l'occurrence, si on veut comparer le code "pascal", ça se ferait comme ça en java

Code :

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

1
2
3
4
 
monObjet.maMethode1();
monObjet.maMethode2();
monObjet.maMethode3();

La bonne blague

Envoyé par bassim

dans ce cas, j'aurais crée un type d'exception pour chaque méthode: Exception1 et Exception2

Code :

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

1
2
3
4
5
6
try {
    monObject.doSomething();
    monObject.doAnotherThing();
} catch (Exception1 ex) {    }
catch (Exception2 ex2) {    }
}

Oui bon là, no comment

(désolé, pas taper, mais c'est plus fort que moi)

**bassim** · 19/12/2007, 17h18

Envoyé par OButterlin

En l'occurrence, si on veut comparer le code "pascal", ça se ferait comme ça en java

Code :

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

1
2
3
4
 
monObjet.maMethode1();
monObjet.maMethode2();
monObjet.maMethode3();

le "with" ne traite pas les exceptions levées par l'une des méthodes, donc, si maMethode1() plante, tu ne risques pas de faire la suivante...

je sais pas si j'ai bien compris ta remarque, mais pourquoi pas ça:

Code :

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

1
2
3
4
5
6
7
8
with monObjet {
try {
maMethode1();
}
catch () {}
maMethode2();
maMethode3();
}

j'ai supposé que le with ici, ne fait qu'ajouter la signature de l'objet

Code :

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

1
2
3
4
5
6
7
8
9
10

	
	Code  :
	Sélectionner tout -
	Visualiser dans une fenêtre à part
	1234  
monObjet.maMethode1();
monObjet.maMethode2();
monObjet.maMethode3();

**bassim** · 19/12/2007, 17h20

Envoyé par bobuse

La bonne blague

Oui bon là, no comment

(désolé, pas taper, mais c'est plus fort que moi)

oui, bon ok je sors

**OButterlin** · 19/12/2007, 17h28

Envoyé par bobuse

La bonne blague

Tu m'étonnes !

**bassim** · 19/12/2007, 17h30

Envoyé par OButterlin

Tu m'étonnes !

vous êtes méchants

**OButterlin** · 19/12/2007, 17h33

Envoyé par bassim

vous êtes méchants

même pas vrai !
en plus j'adorais with

**CyberChouan** · 19/12/2007, 18h12

Contre! Pour la même raison que Bulbo dans son post de la première page...

Je ne suis pas contre le principe de chaînage, mais contre la syntaxe extrêmement ambigüe.

Exemple tordu mais qui a mon sens montre bien les problèmes de la syntaxe si on l'utilise un peu trop rapidement...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Tordu {
   public String att;
 
   public void setAtt(String att) { this.att = att; }
 
   public Tordu faireQuelqueChose() {
      // quelque chose
      return new Tordu();
   }
 
   public void faireAutreChose() {
      // autre chose
   }
}

Et maintenant, imaginons le chaînage:

Code :

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

1
2
3
4
5
Tordu test = new Tordu();
test
   .setAtt("test")
   .faireQuelqueChose()
   .faireAutreChose();

Bon... cette syntaxe abusive de chaînage serait peut-être interdite si une des méthodes n'est pas de type "void" par sécurité, mais il demeure que la syntaxe prête à confusion.

Par contre, je suis pour l'introduction d'une syntaxe de type "with" pour remplacer le chaînage... peut-être un peu plus lourde, mais assez esthétique et intelligible je trouve

**woodwai** · 19/12/2007, 18h17

Le chaînage existe déjà, il suffit de retourner this et on l'obtient (c'est ce qu'on fait souvent avec un StringBuffer). Donc je ne voit pas réellement l'intérêt ...

**lunatix** · 19/12/2007, 18h18

bon, c'est vrai qu'a la reflexion, vaudrait mieux changer la norme javaBean pour avoir le droit de retourner l'instance de la classe dans un seter, et ca serait reglé.

Code :

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

1
2
3
4
public Maclass setMachin(String machin)
     this.machin = machin;
     return this;
}

comme ca, pas de modification du langage, et on peut chainer si on en a envie sans avoir a passer par un builder ou une fluent interface

**adiGuba** · 19/12/2007, 18h39

Envoyé par woodwai

Le chaînage existe déjà, il suffit de retourner this et on l'obtient (c'est ce qu'on fait souvent avec un StringBuffer). Donc je ne voit pas réellement l'intérêt ...

Dans ce cas il faut voter pour la proposition 10 qui permet de pallier les problèmes lorsqu'on couple chainage et héritage

a++