Publicité

Affichage des résultats du sondage: Êtes-vous pour ou contre cette proposition ?

Votants
304. Vous ne pouvez pas participer à ce sondage.
  • Pour

    114 37,50%
  • Contre

    190 62,50%
+ Répondre à la discussion
Page 5 sur 5 PremièrePremière 12345
Affichage des résultats 81 à 95 sur 95
  1. #81
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 35
    Points
    35

    Par défaut

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

  2. #82
    Futur Membre du Club
    Homme Profil pro Denis COCHET
    Développeur Java
    Inscrit en
    juin 2002
    Messages
    29
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis COCHET
    Âge : 36
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2002
    Messages : 29
    Points : 19
    Points
    19

    Par défaut

    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.

  3. #83
    Membre confirmé

    Profil pro
    Inscrit en
    décembre 2005
    Messages
    316
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : décembre 2005
    Messages : 316
    Points : 281
    Points
    281

    Par défaut

    Citation Envoyé par nonilastar Voir le message
    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 ».

  4. #84
    Futur Membre du Club
    Homme Profil pro Denis COCHET
    Développeur Java
    Inscrit en
    juin 2002
    Messages
    29
    Détails du profil
    Informations personnelles :
    Nom : Homme Denis COCHET
    Âge : 36
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2002
    Messages : 29
    Points : 19
    Points
    19

    Par défaut

    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.

  5. #85
    Nouveau Membre du Club
    Inscrit en
    août 2005
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 73
    Points : 35
    Points
    35

    Par défaut

    Citation Envoyé par nonilastar Voir le message
    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!!!

  6. #86
    lvr
    lvr est déconnecté
    Membre chevronné Avatar de lvr
    Responsable de projet fonctionnel
    Inscrit en
    avril 2006
    Messages
    741
    Détails du profil
    Informations professionnelles :
    Activité : Responsable de projet fonctionnel
    Secteur : Arts - Culture

    Informations forums :
    Inscription : avril 2006
    Messages : 741
    Points : 695
    Points
    695

    Par défaut

    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.

  7. #87
    Futur Membre du Club
    Inscrit en
    novembre 2007
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 28

    Informations forums :
    Inscription : novembre 2007
    Messages : 17
    Points : 19
    Points
    19

    Par défaut

    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.

  8. #88
    Membre confirmé
    Avatar de JHelp
    Inscrit en
    octobre 2002
    Messages
    185
    Détails du profil
    Informations forums :
    Inscription : octobre 2002
    Messages : 185
    Points : 277
    Points
    277

    Par défaut

    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 ?

    Citation Envoyé par bulbo Voir le message
    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
    Pour avoir une réponse efficace :
    1) Soyez précis dans vos questions
    2) Choisssez bien votre forum
    3) Consultez la FAQ et la doc avant

  9. #89
    Candidat au titre de Membre du Club
    Inscrit en
    mai 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : mai 2008
    Messages : 10
    Points : 10
    Points
    10

    Par défaut

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

  10. #90
    Invité régulier
    Profil pro Zied Hamdi
    Inscrit en
    juillet 2007
    Messages
    10
    Détails du profil
    Informations personnelles :
    Nom : Zied Hamdi

    Informations forums :
    Inscription : juillet 2007
    Messages : 10
    Points : 7
    Points
    7

    Par défaut oui definitivement

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

  11. #91
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 984
    Points
    984

    Par défaut

    Citation Envoyé par bulbo Voir le message
    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.

  12. #92
    Membre Expert

    Homme Profil pro Chris Camel
    Architecte de système d'information
    Inscrit en
    novembre 2006
    Messages
    1 245
    Détails du profil
    Informations personnelles :
    Nom : Homme Chris Camel
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 245
    Points : 1 650
    Points
    1 650

    Par défaut

    Citation Envoyé par JHelp Voir le message
    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 :
    1
    2
    3
    4
    5
     
    cv.addPoint( 5, 5 )
      .addLine(  0, 0 )
      .addLine( 10,0 )
      .addLine( 10, 10);

  13. #93
    Membre du Club
    Inscrit en
    août 2008
    Messages
    47
    Détails du profil
    Informations forums :
    Inscription : août 2008
    Messages : 47
    Points : 46
    Points
    46

    Par défaut

    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.

  14. #94
    Membre du Club
    Développeur informatique
    Inscrit en
    mai 2004
    Messages
    49
    Détails du profil
    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2004
    Messages : 49
    Points : 57
    Points
    57

    Par défaut

    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 :
    1
    2
    3
    4
    5
    6
    7
    8
     
    with (objet) {
        methode1();
        methode2();
        methode3();
        variable1 = champ1;
        champ2 = variable2;
    }

  15. #95
    Membre à l'essai
    Profil pro
    Inscrit en
    mars 2008
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mars 2008
    Messages : 20
    Points : 20
    Points
    20

    Par défaut Mmmm

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •