IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

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%
Langage Java Discussion :

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


Sujet :

Langage Java

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Par défaut
    Citation Envoyé par azalsup Voir le message
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  2. #2
    Membre Expert

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    Novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 252
    Par défaut
    Pas fondammentalement utile, c'est la simple implémentation du design pattern Builder, qui a ses vertues mais aussi ses faiblesses. D'autant plus que réaliser un builder, c'est simplement retourner this sur les méthodes de fabrication.

  3. #3
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 702
    Par défaut
    Citation Envoyé par azalsup Voir le message
    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)
    Autant le mot clé ou un truc du genre pour marquer la différence et ne pas casser des méchanismes existants me parait une idée valable, autant l'indentaion et une très mauvaise idée car:
    • C'est contraire à un pricipe de base du java. Rajouter des fonctionatilés ne dois pas ce faire à l'encontre des bases du language.
    • Je trouve ça vraiment limitant. Je tiens absolument à rester maitre de l'indentation de mes programmes


    Après y avoir davantage réfléchis à cette proposition, je pense qu'une bonne solution serait d'introduire un nouvel opérateur('..' me parait adapté) qui fonctionerait comme l'opérateur '.' mais retourant l'objet sur lequel il opère plutôt que le résultat de la méthode. On aurait donc:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Thing thing = new Builder()
        ..setSomething(something)
        ..setOther(other)
        .result();
    • On ne change ainsi rien du comportement naturel du type void et de l'opérateur '.'
    • Syntaxe immédiatement identifiable, aucune ambiguité possible.
    • Pas vraiment plus verbeux que la proposition, beaucoup moins qu'un with.

  4. #4
    Membre éclairé

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

    Informations professionnelles :
    Activité : Coach Agile

    Informations forums :
    Inscription : Décembre 2005
    Messages : 316
    Par défaut
    Citation Envoyé par Uther Voir le message
    Après y avoir davantage réfléchis à cette proposition, je pense qu'une bonne solution serait d'introduire un nouvel opérateur('..' me parait adapté) qui fonctionerait comme l'opérateur '.' mais retourant l'objet sur lequel il opère plutôt que le résultat de la méthode. On aurait donc:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Thing thing = new Builder()
        ..setSomething(something)
        ..setOther(other)
        .result();
    • On ne change ainsi rien du comportement naturel du type void et de l'opérateur '.'
    • Syntaxe immédiatement identifiable, aucune ambiguité possible.
    • Pas vraiment plus verbeux que la proposition, beaucoup moins qu'un with.
    Je dois admettre être assez séduit par cette notation.

  5. #5
    Membre habitué
    Profil pro
    Architecte de système d’information
    Inscrit en
    Février 2008
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d’information

    Informations forums :
    Inscription : Février 2008
    Messages : 13
    Par défaut
    Contre !

    Avec un truc comme cela on aurait vraismeblablement des méthodes de type void qui renverait implicitement des objets this en retour (et typé comment ?).

    On ne manquerait pas alors d'avoir des codeur qui tulise les retour de méthode de type void dans el but non avoué de décroché le gros lot des concours de code les plus abscons.

    Je trouve cela tres dangeureux.

    En outre, je suis trés trés contre les longues séquence de code sur une seules lignes qui, quand elle plante ne permettent jamais de savoir qu'elle est la méthode source du soucis.

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Par défaut
    j'étais plutôt pour jusqu'à cet argument
    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.
    Si on est seul à travailler sur son code, je ne vois aucun pb. C'est rarement le cas. Comme ça a été dit par la suite, bonjour l'ambiguïté.

    En fait, comme dans d'autres proposition, il faut essayer (et c'est parfois dur pour moi aussi) de ne pas penser à ce que ça pourrait permettre de pire mais de bien peser le pour et le contre.
    oui je suis d'accord mais il ne faut pas voir non plus uniquement que ce qui est bien il faut justement peser le pour et le contre.

    Pour un apport en lisibilité, je trouve qu'on peut beaucoup y perdre en temps de compréhension de code.


    Car sinon, on n'aurait jamais eu l'opérateur ternaire "? :" en Java !!!
    Bof moi je m'en serai remis. Venant du monde c++, le manque de template ou la liste variable de paramètres, jusqu'à l'arrivée de Tiger, m'a beaucoup plus gêné. C'est pas l'opérateur qui est le plus conseillé pour faire un if. Bien utilisé ça peut apporter mais ça reste très léger comme gain.Il est très souvent utilisé "pour montrer qu'on sait l'utiliser" plus que par nécessité. Cet opérateur n'est pas un plus dans les concepts du langage, n'apporte pas un plus au niveau de la façon de coder, .... le gain est vraiment léger. Donc si cette proposition est du même niveau que cet opérateur alors je suis 2x plus contre cette proposition et qu'ils investissent de leur temps dans d'autres propositions plus intéressantes.

    Moi je suis plutôt contre les apports "esthétiques" si ils n'apportent pas un réel plus. Ou alors, les mettre tout en bas de la pile de priorité.


    edit : éventuellement une différenciation comme pour le coup du ".." pour marquer la différence

  7. #7
    Membre éclairé

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Par défaut
    Je trouve la proposition de départ vraiment pas claire. Avec le with myString {...} ou plus simplement myString{....}, on arrive à quelque chose de mieux.

    Le problème de with, bah c'est pour les programmeurs qui ont utilisés with comme nom de variable. Pas cool pour eux !

  8. #8
    Membre chevronné
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    509
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Avril 2003
    Messages : 509
    Par défaut
    Contre!
    Comme tous les "opposant" je pense qu'avoir indiqué explicitement void en retour d'une methode doit continuer de vouloir dire "void" et pas un this implicite.

    Si le besoins se fait sentir libre au développeur de modifier les méthodes pour qu'elles renvoient l'objet en cours.

  9. #9
    Membre éclairé

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Par défaut
    Citation Envoyé par FreshVic Voir le message
    Si le besoins se fait sentir libre au développeur de modifier les méthodes pour qu'elles renvoient l'objet en cours.
    Pas possible dans le cas des API tiers ou standard.

  10. #10
    Rédacteur
    Avatar de bulbo
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Février 2004
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Février 2004
    Messages : 1 259
    Par défaut
    Citation Envoyé par nicorama Voir le message
    Pas possible dans le cas des API tiers ou standard.
    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
    [Java] [NetBeans] [CVS]
    La FAQ Java
    Merci de ne pas me poser de questions techniques par MP.

  11. #11
    Membre expérimenté
    Avatar de JHelp
    Inscrit en
    Octobre 2002
    Messages
    185
    Détails du profil
    Informations forums :
    Inscription : Octobre 2002
    Messages : 185
    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

  12. #12
    Membre éclairé

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

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    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.

  13. #13
    Membre chevronné
    Profil pro
    Inscrit en
    Avril 2003
    Messages
    509
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France

    Informations forums :
    Inscription : Avril 2003
    Messages : 509
    Par défaut
    Citation Envoyé par nicorama Voir le message
    Pas possible dans le cas des API tiers ou standard.
    Effectivement, et c'est que le concepteur de l'api l'a voulu ainsi en mettant volontairement "void" en retour de ses methodes

  14. #14
    Membre à l'essai
    Inscrit en
    Février 2008
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Février 2008
    Messages : 7
    Par défaut Si on veut, on peut déjà le faire!
    En lisant tous ces post sur les "void",

    Cela m'a fait pensé que la notion de signature de la méthode n'est pas claire.
    Dans java, seuls les paramètres servent à oter les ambiguités en cas de surchage de nom de méthode. le paramètre de retour n'est pas utilisé.

    Le paramètre de retour est utilité seulement si il est assigné ou recepteur d'une nouvelle méthode.

    On peut toujours donc "jeter" le paramètre de retour.

    dans le petit exemple suivant, pour utiliser les chainages dès maintenant, j'ai remplacer void par la classe elle même, et je retourne l'objet (this). Ce qui permet de chainer les appels et ca marche.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    public class Foo {
          int value;
          Foo(int value){this.value=value;}      
          Foo add(int oper1){value+=oper1; return this;}
          Foo mult(int oper1){value*=oper1; return this;}
          int getValue(){return value;
          }
    Son utilisation
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
     
    public static void main(String[] args) {
        Foo f1=(new Foo(1))
                .add(3)
                .mult(4)
                .add(6);
        Foo f2=new Foo(f1.add(3)
                         .add(4)
                         .getValue());
        f2.add(1)                         // on jette la valeur retournée !!
          .mult(4);
        System.out.println(f2.getValue());
       }
    Alors ?

  15. #15
    Membre averti
    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
    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 : 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;
    }

  16. #16
    Membre averti
    Profil pro
    Inscrit en
    Mars 2008
    Messages
    20
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mars 2008
    Messages : 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 : 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é.

  17. #17
    Membre éclairé
    Profil pro
    Inscrit en
    Juillet 2007
    Messages
    802
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2007
    Messages : 802
    Par défaut
    Je suis plutôt contre. C'est vrai que ça réduirait considérablement le code, mais ce serait surtout une source de confusion selon moi. J'ai voté contre sur le principe, mais si cette proposition venait à être adoptée, j'en serais cependant un fervent adepte

  18. #18
    Membre confirmé
    Homme Profil pro
    Inscrit en
    Mai 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Mai 2007
    Messages : 187
    Par défaut
    alors y'aurais plus de methode retournant void?

  19. #19
    Membre Expert Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 702
    Par défaut
    Je pense clairement que "void" doit rester "void". Le fait qu'une fonction void retourne l'objet serait un changement bien trop lourd de conséquences et ouvrirait un gros risque d'abus. L'idée me plait bien mais il faudrait trouver une autre methode.

    Une possibilité (mais pas réalisable car bien trop lourd pour une si faible amélioration) serait de remplacer le "." par autre chose comme "#" qui remplacerait la valeur de retour par l'objet appelé.

  20. #20
    Membre chevronné Avatar de bassim
    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    Février 2005
    Messages
    666
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Février 2005
    Messages : 666
    Par défaut
    En Pascal , si je me rappelle bien on fait comme ça:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    with monObjet do
    begin
    setSomething();
    setChose();
    traitemant();
    end;
    en java ça serait:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    with monObjet {
    setSomething();
    setChose();
    traitement(getChose());
    }
    qu'en pensez vous ?

Discussions similaires

  1. Réponses: 165
    Dernier message: 03/09/2009, 15h35
  2. Réponses: 78
    Dernier message: 27/08/2009, 19h29
  3. JDK 7: Proposition 5 : extensions de méthodes
    Par vbrabant dans le forum Langage
    Réponses: 75
    Dernier message: 19/10/2008, 13h32
  4. JDK 7: Proposition 3 : Comparer les énumérations
    Par vbrabant dans le forum Langage
    Réponses: 52
    Dernier message: 19/10/2008, 12h36
  5. Réponses: 27
    Dernier message: 19/10/2008, 11h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo