Discussion :

[zegreg]

Je suis contre.

1) Je trouve primo que faire des chaînages ne devraient pas faire partie des "best practices". Comme déjà dit, en cas d'exceptions ça devient difficile à debuger et en plus question lecture de code, ce n'est pas terrible. Alors ajouter des facilités pour des mauvaises habitudes, non.
2) void ce n'est pas this, ça ne tient pas debout. Pour les adeptes des chaînages vous n'avez qu'à retourner l'objet qu'il faut dans votre méthode.
3) Je vois vraiment pas le gain... C'est plus rapide? A quel point de vue? Relecture du code? Debugage? A part ajouter de l'incohérence dans le langage (void <> this), je vois pas trop ce que ça ferait...

[nonilastar]

Dans une utilisation raisonné ça peut améliorer la lisibilité du code. Il faut se donner des limites et je pense que cette amélioration peut être forte avantageuse.

[jproto]

Dans une utilisation raisonné ...

Malheureusement, il me semble illusoire de penser que ton voisin, ou l’intervenant externe en mission chez toi pour 3 semaines aura la même notion que toi de « l'utilisation raisonnée ».

[nonilastar]

En effet, peut-être que mon voisin ou l'intervenant ne saura pas respecter les règles de codage que je souhaites mettre en place dans mon service. Le rôle d'un chef de projet peut aussi passer par une revue de code hebdomadaire pour vérifier ces règles et faire des réajustements si nécessaire. Donc il me parait pertinent de pouvoir utiliser cette syntaxe qui, comme toutes les améliorations proposées dans V7 et dans les précédentes, ne sont pas obligatoirement utilisable. C'est une boite à outils qu'il faut réguler pour que la lisibilité et le debuggage du code soit cohérent pour tous les intervenants d'un projet.

[zegreg]

Dans une utilisation raisonné ça peut améliorer la lisibilité du code. Il faut se donner des limites et je pense que cette amélioration peut être forte avantageuse.

Je vois pas en quoi ça peut apporter de la lisibilité (... .maMethode vs obj.maMethode) avec ce qui existe déjà, désolé... Encore une fois les chainages devraient être évités. Ou comme j'ai déjà dit, fait un return this dans tes setters, si ça démange tant que ça de faire des chaînage. En tout cas pour moi c'est une très mauvaise idée qui n'ajouterait que de l'incohérence au niveau de la logique, void c'est n'est pas this!!!

[lvr]

Contre.

void c'est void. Donc si le designer de la classe n'a pas prévu de retourner l'objet, il n'y a pas de raison de contourner ce choix.

[TPReal]

Exactement, void c'est void. Si on veut construire choses comme objet.met1().met2(). ..., on peut bien changer les types, et retourner 'this' a la fin de chacune method.

[JHelp]

Résolument contre.
Je penses pas que ça soit plus clair, au contraire on a bien du mal à comprendre ce que fait une longue ligne d'instruction. C'est comme les phrases vaut mieux des courtes que des interminables. Sinon on en perd le début en les relisant.
Et puis void c'est void, pourquoi changer son type ?

Et quel est le gain ? C'est surtout ça qu'il faut voir..

- Est-ce que cela permet de faire quelque chose d'impossible auparavant ? Non, on ne chainait pas mais c'est juste du sucre syntaxique, juste une nouvelle manière d'écrire les appels aux méthodes.

- Est-ce que c'est plus lisible: Non si une méthode ne retourne pas void au milieu de l'enchainement on va appeler une méthode sur un autre objet en cours de route.

- Est-ce plus maintenable: Non en cas d'exception il y a je ne sais pas combien d'appels sur la même ligne, attention a ne pas se planter lors de l'analyse du chainage qui a provoqué l'exception.

- Est-ce plus rapide a écrire: oui on économise le nom de la variable, quelle fête..

- Est-ce que cet avantage vaut le coup d'introduire tout ces inconvénients sachant que ça ne permet rien de nouveau au final ?

Lorsque j'étais encore a la fac et qu'on nous farcissait la tête de conseils pour écrire du code propre, il y avait ce petit conseil parmi d'autre, genre aéré votre code, pas plus d'une instruction par ligne ... pour moi la il y a conflit avec la proposition.
Et aller a la ligne pour chaque chainage n'est pas beaucoup plus propre car il manquera une info sur la ligne, la variable, qu'il faudra aller chercher je ne sais pas combien de lignes plus haut..

Bien souvent on n'écrit le code qu'une fois mais on le relit plusieurs, je préfère perdre du temps une fois si ça m'en fait gagner plusieurs fois par la suite..

Bulbo

+1

JHelp

[pala00]

Contre aussi pour diverses raison évoquées précédemement mais aussi parce que ça limite l'extension suivante:

Vous faites une méthode qui renvoi void, et vous voulez changer la methode pour quelle renvoi true ou false par exemple. Vous allez casser tous les codes qui font du chainage.

le .. me plait bien.

sinon avoir un self plutot qu'un void dans la déclaration de la fonction:

genre

Code :

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

1
2
3
public self setTime(){
...
}

quel intéret:

-pas besoin de faire le return this il est implicite:
-la déclaration précise que le type renvoyé EST this et pas une copie.
-l'objet renvoyé est du même type que l'objet d'origine, donc pas de problème de cast dans un hierarchie.

prenons le cas actuel:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class Toto{
   public Toto setTime(){
     // fait un truc
   return this;
  }
}
public class SubToto extends Toto{
   public SubToto print(){
     // fait un autre  truc
   return this;
  }
}
 
SubToto toto=new SubToto();
toto.setTime().print();  // <- ne marche pas setTime renvoie Toto qui n'a pas 
                               // de méthode print

[zhamdi]

Une méthode void peut très bien retourner l'instance meme. Ce code ne destabilise pas...

[nicorama]

Lorsque j'étais encore a la fac et qu'on nous farcissait la tête de conseils pour écrire du code propre, il y avait ce petit conseil parmi d'autre, genre aéré votre code, pas plus d'une instruction par ligne

T'as de la chance, mon prof de C du CMI de Marseille écrivait tout un programme sans une boucle for(){}. Imbitable.
Je suppose que ce genre de proposition lui ferait plaisir.

[Tommy31]

Résolument contre.
Je penses pas que ça soit plus clair, au contraire on a bien du mal à comprendre ce que fait une longue ligne d'instruction. C'est comme les phrases vaut mieux des courtes que des interminables. Sinon on en perd le début en les relisant.

Si c'est bien indenté ca peut passer:

Code :

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

1
2
3
4
5
 
cv.addPoint( 5, 5 )
  .addLine(  0, 0 )
  .addLine( 10,0 )
  .addLine( 10, 10);

[nonpoluant]

D'accord, mais pas ecrit de cette façon. Comme je l'ai déjà lu dans d'autres postes, il faudrait une autre syntaxe. Donc j'vote pas.

[lex2004]

Je suis très contre!

Cela pourrait prêter à confusion sur le type de retour d'une méthode. Je serais plutôt pour un emprunt au langage Pascal:

Code :

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

1
2
3
4
5
6
7
8
 
with (objet) {
    methode1();
    methode2();
    methode3();
    variable1 = champ1;
    champ2 = variable2;
}

[fridobox]

C'est vrai que le chaînage est un confort d'écriture.

Je ne suis pas pour le remplacement du type de retour. Comme certains l'on dit, ce n'est pas parce qu'une méthode retourne void que son action porte sur l'instance this.
J'ai eu par exemple une méthode copyAttributs(Object o) qui permettait de faire de o un clone de this. Chaîner cette méthode retournerait this alors qu'on souhaiterait travailler sur le clone o.
Et puis, c'est vrai qu'il vaut mieux prévoir cela dès la création de la classe (comme StringBuffer par exemple).

Je suis pour l'utilisation d'un bloc with.
Pour moi, cela devrait redéfinir l'instance implicite (qui actuellement est this) dans ce bloc. A l'intérieur du bloc, l'utilisation de this doit donc être explicite.
C'est par exemple utile pour une IHM :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class MyFrame extends JFrame {
 
  JLabel b;
 
  public MyFrame() {
    setText("my frame"); // c'est implicitement this.setText
    b = new JLabel();
    with b {
      setText("my label"); // c'est implicitement b.setText
      setBackground(Color.BLUE); 
      this.getContentPane.add(); // this doit être explicité et c'est implicitement add(b)
    }
    pack(); // c'est implicitement this.pack()
    setVisible(true); 
  }
}

Cela permet entre autre de faire évoluer le code à l'intérieur du bloc sans risquer de se tromper d'instance. C'est le risque lorsqu'il y a plusieurs objets du même type (par exemple Label b1 et Label b2), un mauvais copier/coller est vite arrivé.