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

Java Discussion :

Le 7/7 c'est Java 7


Sujet :

Java

  1. #21
    Expert éminent sénior
    Citation Envoyé par Uther Voir le message

    Normalement ça devrait être bien plus rapide : le travail sur les nouveautés a venir est bien entamé. Java 7 est juste une sorte de pré-Java 8.
    De mémoire, java 8 est prévu pour fin 2012 (dans 1.5 an). Pour le reste, oracle envisage le cycle
    java 7: sucre
    java 8: gros changements
    java 9: sucre
    java 10: gros changements

    etc. avec des cycles de 1.5 an
    David Delbecq Java developer chez HMS Industrial Networks AB.    LinkedIn | Google+

  2. #22
    Expert éminent
    Citation Envoyé par tchize_ Voir le message
    A pitié, par les types variant, ca a des tonns de p** d'effets de bord. La syntaxe diamant a pour but d'éviter de ce répéter, pas de créer des types variables.
    Désolé de te faire pitié mais sur ce coup t'es pas à jour. Le mot clef var en c# ne désigne en rien un type variable, écrire :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    var table = new Hashtable<int, List<Client>>()


    est strictement équivalent à

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    Hashtable<int, List<Client>> table = new Hashtable<int, List<Client>>()


    Le type est connu à la compilation et n'a aucune ambigüité. Si tu venais à déclarer.

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    var liste = null;


    Ca ne compilerait pas car l'inférence du type n'est pas possible. Ca n'a absolument rien à voir avec un type "variable", c'est un pur sucre syntaxique et toute la force du typage est préservée sans compromis.

    Mais cela permet d'écrire

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
     
    foreach(var listeClient in table.Values )


    Alors qu'en java il ne sera probablement pas possible d'écrire autrement que :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
     
    for( List<Client> listeClient : table.values() )


    Après on aime ou on aime pas, perso j'apprécie car ça m'évite de devoir faire le boulot à la place du compilateur.

  3. #23
    Expert éminent sénior
    Citation Envoyé par _skip Voir le message
    Désolé de te faire pitié mais sur ce coup t'es pas à jour. Le mot clef var en c# ne désigne en rien un type variable, écrire :
    ok merci pour l'info, je suis pas trop c#

    Pour le diamant, je sais qu'il y a eu beaucoup de discussion a l'époque pour savoir si il fallait inférer à gauche, à droite, des deux coté, et quand on infère de savoir dans quel règles on applique. Dans tous les cas où on regardais le problème, il y avait des pour et des contres, et comme toujours, il faut finir par prendre une décision.

    L'avantage avec le diamant c'est qu'on peut faire des choses du genre

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    MonType<Map<String,String>> donnee;
    if (condition)
      donnee = new MonSousType<>();
    else
      donnee = new MonTypeReadOnly<>();

    Le type du stockage n'est pas 100% contraint par le type de la déclaration.
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  4. #24
    Membre actif
    En 1 mot : Super !

  5. #25
    Expert éminent sénior
    Citation Envoyé par _skip Voir le message
    Mais cela permet d'écrire
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
     
    foreach(var listeClient in table.Values )
    C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

    A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.

  6. #26
    Membre expérimenté
    Citation Envoyé par Uther Voir le message
    C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

    A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.
    Le type, c'est IEnumerable<T>. Dans le contexte d'un foreach, c'est vraiment tout ce qui est utile de savoir.

  7. #27
    Membre actif
    J'adore ces nouveautés. Et surtout le syntaxe "diamond". Mais je me demande si la dernière version d'Eclipse reconnait ce syntaxe.

  8. #28
    Membre habitué
    Citation Envoyé par ratomms Voir le message
    J'adore ces nouveautés. Et surtout le syntaxe "diamond". Mais je me demande si la dernière version d'Eclipse reconnait ce syntaxe.
    En tout cas, Netbeans la reconnaît :-)

  9. #29
    Expert éminent sénior
    En effet Netbean 7 et Eclipse 3.7 gèrent déjà les nouvelles syntaxes de Java 7.

  10. #30
    Expert éminent
    Citation Envoyé par Uther Voir le message
    C'est particulièrement pour cette raison que je n'aime pas cette notation : dans ce cas, le type de la variable listeClient n'est pas evident au premier coup d'oeil.

    A mon avis, le fait d'avoir systématiquement le type de la variable en début de déclaration apporte vraiment un plus à la lisibilité.
    C'est une question d'habitude je pense... Et de préférence. Perso je me contente d'une variable bien nommée dans ce genre de cas pour deviner le type, sachant que le compilateur est là pour me dire si je me trompe.

    Des goûts et des couleurs quoi... Pourtant autant parfois dans des langages comme scala je trouve que le désir d'être concis va parfois trop loin, autant là ça ne m'aurait pas dérangé d'épargner quelques frappes.

    Enfin plus directement, j'espère que pour java 8 nous aurons une chance de voir émerger un sucre syntaxique pour les propriétés. Les spec javabeans nous obligeant à créer des pairs get/set plutot que de laisser public les membres, ça ferait sens d'alléger nos Pojo et dto.

  11. #31
    Expert éminent sénior
    ce qui m'ennuie quand on ne précise pas le type, c'est que si demain la méthode retourne un sous type avec des méthodes supplémentaire (genre machin(String) en plus de machin(Object), le code va changer de sens, alors que si on avait sagement visé le type connu au moment de la création du code (exemple une interface X) machin(String) n'entrerais jamais dans l'équation.

    Bref c'est un des nombreux effets de bord qui ont du être pirs en compte dans la décision je suppose

    Sans compter qu'un typeage automatique, ca va au delà de facilité l'utilisation des generic
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  12. #32
    Modérateur

    Underscores in numeric literals

    ça fait franchement bizarre d'écrire un nombre de cette façon
    Java recommande d'utiliser les majuscules pour démarquer les mots
    Certe, cher Uther, mais je trouve cet argument un peu spécieux.
    Car Java nous a habitué à lire des constantes avec autant d'"underscores" qu'un curé peut en bénir :
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    JOptionPane.INITIAL_SELECTION_VALUE_PROPERTY

    Mais bon, on n'est pas obligé de s'en servir. C'est plus rigolo qu'autre chose.

    Strings in switch

    Enfin une copie de fichier simple

    Détection de modification de fichiers
    Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)

    Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cour...eloppons/java/

  13. #33
    Expert éminent sénior
    Citation Envoyé par Népomucène Voir le message

    ça fait franchement bizarre d'écrire un nombre de cette façon
    Entre nous, tu préfère tomber sur un code où une constante est écrite

    100_000_000
    ou
    100000000

    moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  14. #34
    Expert confirmé
    Citation Envoyé par tchize_ Voir le message
    Entre nous, tu préfère tomber sur un code où une constante est écrite

    100_000_000
    ou
    100000000

    moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.
    Personnellement j'aurais préféré 100 000 000, mais c'est vraiment du pinaillage.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  15. #35
    Expert éminent sénior
    Citation Envoyé par tchize_ Voir le message
    Entre nous, tu préfère tomber sur un code où une constante est écrite

    100_000_000
    ou
    100000000

    moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.
    100*1000*1000;

    ou encore

    MILLE = 1000;
    MILLIONS = MILLE * MILLE;
    JACKPOT = 185 * MILLIONS;
    Developpez.com: Mes articles, forum FlashPascal
    Entreprise: Execute SARL
    Le Store Excute Store

  16. #36
    Expert éminent
    Citation Envoyé par tchize_ Voir le message
    ce qui m'ennuie quand on ne précise pas le type, c'est que si demain la méthode retourne un sous type avec des méthodes supplémentaire (genre machin(String) en plus de machin(Object), le code va changer de sens, alors que si on avait sagement visé le type connu au moment de la création du code (exemple une interface X) machin(String) n'entrerais jamais dans l'équation.
    En même temps, de mon point de vue ton exemple d'introduction d'un overload incompatible dont le type en paramètre est une sous-classe d'un autre type pour lequel il existe déjà un overload est un "code smell" qui peut tout à fait flinguer un code style :

    x.machin( y.chose() )

    Bref pour moi c'est une erreur de programmation qui n'est pas directement liée à l'inférence de type. Enfin j'arrête là parce que ça devient HS.

  17. #37
    Modérateur

    Citation Envoyé par tchize_ Voir le message
    Entre nous, tu préfère tomber sur un code où une constante est écrite

    100_000_000
    ou
    100000000

    moi, au moins, dans le premier cas je vois immédiatement que la constante vaut 100 millions Dans le deuxième je dois balader mon curseur pour compter les 0.
    Oui, certes, j'ai bien saisi que la lecture en est grandement facilitée.

    Mon étonnement vient qu'après des années et des années d'informatique de gestion,
    j'ai très rarement écrit une constante en dur dans un programme (ou alors dans les tests).
    La dernière, je crois, c'était 6.55957 lors du passage à l'€uro !

    Dès lors je me demande pourquoi consacrer de l'énergie pour une question de présentation qui n'arrive que rarement.
    Mais peut-être que mes chers confrères vont me trouver quelques cas d'utilisation intensive des constantes
    Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)

    Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cour...eloppons/java/

  18. #38
    Expert éminent sénior
    toutes les constantes ne sont pas bonnes a exporter. Si tu demande à ce que l'affichage se fasse en millions d'euros, par exemple, tu va surement faire un truc du genre
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    int arrondi = Math.round(montant/1_000_000);
    David Delbecq Java developer chez HMS Industrial Networks AB. &#12288;&#12288;&#12288;LinkedIn | Google+

  19. #39
    Expert éminent sénior
    Citation Envoyé par Népomucène
    Certe, cher Uther, mais je trouve cet argument un peu spécieux.
    Car Java nous a habitué à lire des constantes avec autant d'"underscores" qu'un curé peut en bénir
    Ca fait aussi partie des recommandation java :
    - NomDeClasse pour les classes
    - nomDeVariable pour les méthodes,variables, ...
    - NOM_DE_CONSTANTE pour les constantes.

    Citation Envoyé par Népomucène
    Dès lors je me demande pourquoi consacrer de l'énergie pour une question de présentation qui n'arrive que rarement.
    Mais peut-être que mes chers confrères vont me trouver quelques cas d'utilisation intensive des constantes
    C'est probablement parce que tu fait de la gestion et que tu n'as pas a manipuler souvent de l'hexadécimal ou du binaire.
    Pouvoir faire des séparation dans un nombre décimal est juste un léger plus, mais pour la notation binaire, c'est juste indispensable pour rester lisible.

  20. #40
    Modérateur

    En effet ...
    Me voilà donc convaincu de l'intérêt de la chose
    Labor improbus omnia vincit un travail acharné vient à bout de tout - Ambroise Paré (1510-1590)

    Consulter sans modération la FAQ ainsi que les bons ouvrages : http://jmdoudoux.developpez.com/cour...eloppons/java/

###raw>template_hook.ano_emploi###