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

[elitost]

J'aime bien ce genre de raccourci de code, souvent moins lisible, mais avec l'habitude...

[nicorama]

C'est un raccourci de codeur de C, qui mettent tout un programme dans un for. Je ne l'utiliserai jamais, c'est une façon de comprendre la grammaire très différente, et à priori je ne vois pas pourquoi j'en empêcherai les autres.

Sauf qu'à trop faire ce genre de variance, je vais tirer la gueule le jour où il faudra débugguer le programme d'un collègue. Et dans le cadre des projets open-source, merci la sère-mi !
Donc contre.

[benwit]

Du même avis que CyberChouan, Bulbo et woodwai.

Envoyé par CyberChouan

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

On peut déjà le faire en retournant this.
Je vais voir la proposition 10...

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

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

[Alec6]

Est ce qu'on finira comme en java script hihi

CONTRE !

Ctrl C ctrl V c'est pas long
Comprendre le code d'un autre ca l'est par contre.

Est ce qu'une méthode avec void ne renvoie pas true ou 1 quand son process a fonctionné ?

[ludosoft]

Envoyé par 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...

Oui c'est le genre de truc dont il ne faut pas abuser (comme le fameux "goto"). Moi aussi j'ai eu ce genre de galère avec des with dans des blocs dépassant la hauteur de l'écran...

Désolé d'avoir réveillé ton mal de crane !

[xavlours]

Contre.

Après l'expérience des StringBuilders, l'apport est anecdotique. Au contraire il est plus facile de relire la répétition d'une variable qu'un chaînage.

Au pire, pour les grosses feignasses avec de longs chaînages on peut toujours mettre un bloc d'accolade pour utiliser un alias court de la variable.

[kalysto]

Je ne vois pas trop en quoi ca apporte quelque chose au langage Java ?
On peut deja le faire (regardons StringBuilder), c'est juste un détail d'implémentation.

Si le question est faut-il généraliser cet emploi, j'avouerais que je suis plutot pour, genre certaines classe du JDK pourront supporter ces invocations chainées. Mais il faut que ca reste à la discretion du développeur.

La, on parle de toutes les methodes qui retournent void retourneraient plutot this, et ca de facon systematique ? Je trouve que c'est un peu bizarre, ca touche finalement aux interfaces que le developpeur fournit. Si il ne controle plus ses types de retour ou s'il veut empecher le chainage, comment va-il faire ?

[jproto]

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

Code :

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

[zais_ethael]

Envoyé par bulbo

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.

[Alesque]

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.

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

Envoyé par Alesque

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 !

[jproto]

Envoyé par jproto

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

Code :

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.

[Amine_sas]

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

[ripounet]

- pas d'apport significatif
- bonjour le debug pas à pas ... même en étalant sur plusieurs lignes, c'est très pénible

[FranT]

[QUOTE=bassim;2781310]En Pascal , si je me rappelle bien on fait comme ça:

Code :

1
2
3
4
5
6
with monObjet do
begin
setSomething();
setChose();
traitemant();
end;

en java ça serait:

Code :

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

Quand je me suis mis à Java, c'est l'une des premières choses que j'ai regrettées par rapport à Pascal/delphi. Je suis pour à 100%.

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

[bulbo]

Envoyé par 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)

L'indentation dans un langage c'est n'imp, comment compter des caractères invisible ? Super idée qu'ils ont eu en python, bien heureux qu'on ai pas ça en java moi.

Bulbo