Discussion :

[vbrabant]

Aujourd'hui :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Builder {
    void setSomething(Something x) { … }
    void setOther(Other x) { … }
    Thing result() { … }
}
 
Builder builder = new Builder();
builder.setSomething(something);
builder.setOther(other);
Thing thing = builder.result();

Demain :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class Builder {
    void setSomething(Something x) { … }
    void setOther(Other x) { … }
    Thing result() { … }
}
 
Thing thing = new Builder()
    .setSomething(something)
    .setOther(other)
    .result();

En combinant cette proposition avec la proposition 5, il serait possible d'écrire du code de ce style :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
import static java.util.Collections.sort;
 
List<String> strings = ...;
 
strings
    .filter(isCountryName) // could be a closure
    .sort()
    .uniq()
    .each(printString); // ditto

[Napalm51]

Pour, je prend l'exemple de la classe GBC servant à utiliser facilement les GridBagConstraint qui utilise ce principe, et c'est tellement plus simple lors de la création d'enchaîner quelques setters

[Uther]

Autant le principe me plait, autant je pense qu'il faudrait revoir la syntaxe car la on utilise le "." classique alors que le retour de type void, ca me choque.

[lunatix]

oui oui, sans hésiter une seconde sur le chainage ! c'est tellement plus lisible, ca n'apporte aucune complexité supplementaire dans le langage.
j'avais parlé de ce que ca apporte dans un billet de mon blog

de plus, c'est une approche (le chainage) qu'on trouve deja dans certaines api java (java.nio par exemple) : autant le généraliser.

le type même de modif que j'aime bien : simple, ca ne n'apporte pas de nouveaux mots clés, comprehensible facilement.

[austin P.]

pour

j'irai même plus loin
c'est beaucoup plus lisible en chainage qu'avec le nom de l'objet repété X fois

[bobuse]

Tout à fait d'accord aussi !!

Par contre, je ne vois pas de condition explicite. J'imagine que ce chaînage ne s'appliquerait que pour les méthodes qui retournent void.

En fait, ça me conforte dans l'idée que ce serait mieux d'utiliser des exceptions qu'un code de retour, comme c'est le cas dans Collection.add(E) par exemple. En effet, le chaînage ne serait pas possible à cause de ce code de retour !!

[bulbo]

Contre,

Pour moi c'est du grand n'importe quoi et pourquoi pourrait on chainer les méthodes retournant void (avec un this implicite) et pas les méthodes retournant un type particulier ou du coup pas de this mais le type de retour.

Pour lire (et comprendre) un chainage de ce type en mixte (avec et sans void) il faudrait connaitre par cœur la déclaration de chacune des méthodes .. personnellement j'en suis incapable et même avec un IDE ça peut être pénible a voir.

En général si j'ai ce genre d'enchainement a faire il y a probablement une raison et peut-être aussi le besoin de le faire a différents endroits du coup je mets ça dans une méthode et zou

Bulbo

[adiGuba]

Pour lire (et comprendre) un chainage de ce type en mixte (avec et sans void) il faudrait connaitre par cœur la déclaration de chacune des méthodes .. personnellement j'en suis incapable et même avec un IDE ça peut être pénible a voir.

En effet il y a un gros risque d'ambiguité lors de la lecture...
Du coup la proposition 10 semblerait plus clair sur ce point précis concernant le chainage

a++

[Jester]

Contre,

return this; si on veut pouvoir le faire.

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

[adiGuba]

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

[ludosoft]

J'avoue que l'idée est bonne mais manque de clarté dans sa "syntaxisation".

Autant que je me souvienne en Pascal il y a une syntaxe (avec le mot clé "with") qui permettait d'aboutir à se genre de simplification :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Builder {
    void setSomething(Something x) { … }
    void setOther(Other x) { … }
    Thing result() { … }
}
 
with new Builder(){
    setSomething(something);
    setOther(other);
    Thing thing = result();
}

Notez qu'il reste à savoir quelle serait la porté de thing.

[mbaumeler]

Venant de faire de la maintenance de code sur un projet Delphi/Pascal la possibilité offerte avec le with donne du code illisible et c'est la galère pour bosser dessus...
C'est illisible, ça fout le bordel et merci les mals de cranes...

[jproto]

L’exemple donné me laisse penser que cela peut s’appliquer avec un type de retour puisqu’il est présenté :

Code :

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

1
2
3
4
5
 
Thing thing = new Builder()    
         .setSomething(something)    
         .setOther(other)    
         .result();

Or result() retourne bien un objet (a moins que je sois passé à côté de quelque chose).

C’est là le seul point que je trouve beaucoup moins clair, et qui me laisse dubitatif.

[Gargamail]

Je ne suis pas fan des chaînages. Comme on l'a si bien dit avant moi, on est perdu et on ne sait plus quel objet on manipule au final.

Et puis, regardez la méthode add(Object) de Collection. Elle renvoie un boolean qui peut être très utile. Si on encourage le chaînage, on va chercher à renvoyer this (ou un void interprété comme un this) et perdre cette information utile.
Je dis « Non ! ».

[jproto]

L’exemple donné me laisse penser que cela peut s’appliquer avec un type de retour puisqu’il est présenté :

Code :

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

1
2
3
4
5
 
Thing thing = new Builder()    
         .setSomething(something)    
         .setOther(other)    
         .result();

Or result() retourne bien un objet (a moins que je sois passé à côté de quelque chose).

C’est là le seul point que je trouve beaucoup moins clair, et qui me laisse dubitatif.

OK, je reprends ce que j'ai dis, j'étais bien à côté de la plaque.

Perso, maintenant que j'ai changé de céréales le matin, et que j'y vois donc un peu plus clair, je vote contre.
Sincèrement, je n'y vois pas là un gain en lisibilité, bien au contraite.

[zais_ethael]

Pour moi c'est du grand n'importe quoi et pourquoi pourrait on chainer les méthodes retournant void (avec un this implicite) et pas les méthodes retournant un type particulier ou du coup pas de this mais le type de retour.

C'est une sorte de bonne règle de programmation utilisés par certains pour optimiser la syntaxe. Plutot que de faire renvoyer void à une méthode ("rien", donc c'est inutile), autant renvoyer this à la place.

Néanmoins je suis assez d'accord avec toi. Autant présenté comme ça ça pourrait peut-être être utile, autant on ne peut pas nier que c'est bizarre, et comme je n'ai jamais vu de truc semblable dans un autre langage je serais plus enclin de voter contre.

[djo.mos]

J'ai voté contre.
Comme évoqué précédemment, ceci peut être réalisé (et est fait dans de nombreux apis existants) en retournant this.
Je crois aussi que ceci prête à confusion...
Bref, je deteste un peu le fait que quelque chose ne se comporte pas exactement de la façon qu'elle était censé faire .. Une méthode qui retourne void est censée être appelé dans une instruction, et puis c'est tout !

J'ai voté contre car à mon humble avis c'est plus un problème de design d'une API plutôt qu'une feature à ajouter au niveau du langage lui même.

Si on veut ce genre de comportement, il suffit de retourner this sur les setter.

Exactement !

[Amine_sas]

Contre,
Je ne trouve pas ça très élégant.

[azalsup]

J'ai voté oui mais il faudra revoir la syntax. Car ca va etre un peu illisible.

Personnellement j'opte pour deux solution :
- 1 : un mot clee genrs last ou self ( un peu comme le this)
- 2 : prendre en compte l'indentation (comme en python)