J'aime bien ce genre de raccourci de code, souvent moins lisible, mais avec l'habitude...
Version imprimable
J'aime bien ce genre de raccourci de code, souvent moins lisible, mais avec l'habitude...
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.
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 :
Notez qu'il reste à savoir quelle serait la porté de thing.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(); }
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...
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é ?
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.
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 ?
L’exemple donné me laisse penser que cela peut s’appliquer avec un type de retour puisqu’il est présenté :
Or result() retourne bien un objet (a moins que je sois passé à côté de quelque chose).Code:
1
2
3
4
5 Thing thing = new Builder() .setSomething(something) .setOther(other) .result();
C’est là le seul point que je trouve beaucoup moins clair, et qui me laisse dubitatif.
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 ! ».
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.
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.
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 !
Exactement !
Contre,
Je ne trouve pas ça très élégant.
- pas d'apport significatif
- bonjour le debug pas à pas ... même en étalant sur plusieurs lignes, c'est très pénible
[QUOTE=bassim;2781310]En Pascal , si je me rappelle bien on fait comme ça:
en java ça serait:Code:
1
2
3
4
5
6 with monObjet do begin setSomething(); setChose(); traitemant(); end;
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%.Code:
1
2
3
4
5 with monObjet { setSomething(); setChose(); traitement(getChose()); }
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)