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

[bobuse]

Envoyé par bassim

comme ceci donc :

Code :

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]

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]

Envoyé par bassim

en java ça serait:

Code :

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]

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]

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 :

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

Bulbo

[romaintaz]

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 :

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]

Contre,

return this; si on veut pouvoir le faire.

[OButterlin]

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

Code :

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]

Code :

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 :

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

[adiGuba]

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]

Envoyé par OButterlin

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

Code :

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 :

Oui bon là, no comment
(désolé, pas taper, mais c'est plus fort que moi)

[bassim]

Envoyé par OButterlin

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

Code :

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 :

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 :

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

	
Code  :
        
	
1234
 
monObjet.maMethode1();
monObjet.maMethode2();
monObjet.maMethode3();

[bassim]

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]

Envoyé par bobuse

La bonne blague

Tu m'étonnes !

[bassim]

Envoyé par OButterlin

Tu m'étonnes !

vous êtes méchants

[OButterlin]

Envoyé par bassim

vous êtes méchants

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

[CyberChouan]

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 :

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 :

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]

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]

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 :

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]

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