Publicité

Affichage des résultats du sondage: Etes vous pour ou contre cette proposition ?

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

    280 76,09%
  • Contre

    88 23,91%
+ Répondre à la discussion Actualité déjà publiée
Page 4 sur 4 PremièrePremière 1234
Affichage des résultats 61 à 79 sur 79
  1. #61
    Invité régulier
    Inscrit en
    février 2008
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 7
    Points : 8
    Points
    8

    Par défaut

    dans l'exemple qui est donné je ne suis pas tellement gêné par la répétition, c'est plus l'absence de désignation de ce générique qui est problématique!

    à la place de

    Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

    Je préférai:

    generic <String, List<String>> AnagramItem;
    ...
    Map<AnagramItem> anagrams = new HashMap<AnagramItem>();

    ce qui permettrait de facilement remplacer un type générique partout,

    de faire de l'introspection sur les types génériques ...

  2. #62
    Rédacteur/Modérateur

    Avatar de bouye
    Homme Profil pro Fabrice Bouyé
    Développeur Java
    Inscrit en
    août 2005
    Messages
    4 534
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabrice Bouyé
    Âge : 38
    Localisation : Nouvelle-Calédonie

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Agroalimentaire - Agriculture

    Informations forums :
    Inscription : août 2005
    Messages : 4 534
    Points : 13 098
    Points
    13 098
    Billets dans le blog
    1

    Par défaut

    Pas vraiment non car pouvoir faire de la reflection suppose que le bytecode stocke quelque part une information sur le type utilise ce qui n'est actuellement pas le cas (dans leur implementation actuelle, les generics ne sont que du sucre syntaxique pre-compilation pour eviter les casts manuels) sans que le programmeur ne s'en charge lui-meme.

    Par contre, un typedef ou equivalent n'etait-il pas en discussion pour cette release ou une suivante ???
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  3. #63
    Membre habitué
    Inscrit en
    mars 2005
    Messages
    148
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 148
    Points : 111
    Points
    111

    Par défaut

    Je ne vois qu'un seul mauvais point mais il suffit de rendre les 2 écritures possibles pour assurer la compatibilté ...

    Perso,
    Code :
    List<String>list = new Arraylist<String>();
    me choque moins que
    Code :
    List<String> list = new ArrayList();
    C'est pas un gros plus mais il n'y a pas d'inconvénient.

    donc pour

  4. #64
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 673
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 673
    Points : 7 849
    Points
    7 849

    Par défaut

    Si si, c'est un grand plus:

    Code :
    1
    2
    3
    4
     
    private GenericCache<GenericTripleKey<Long, Long, Long>, DateVals<List<Data>>> fillCache =
     new GenericCache<GenericTripleKey<Long, Long, Long>, DateVals<List<Data>>>(
    			100, 0);
    Un extrait de code dans l'application sur laquelle je travaille

  5. #65
    Membre Expert
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 254
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 254
    Points : 1 382
    Points
    1 382

    Par défaut

    Ce qui me choque moi, ce cas de figure (extrême, je l'admets, mais tout de même) :

    Code Java :
    1
    2
    3
    4
    5
    List<String> chaines = new ArrayList();
    chaines.add(...);
    chaines.add(...);
    ...
    Set<Date> dates = new TreeSet(new HashSet(new LinkedHashList(new LinkedList(chaines))));

    Qu'en penser ? La vérification se fait sur le TreeSet attribué à dates et non en amont, tandis qu'avec la déclaration explicite c'est bien plus compréhensible au premier coup d'œil et le compilateur pointe très précisément du doigt l'erreur.

  6. #66
    Invité
    Invité(e)

    Par défaut arrêtez de compliquer le langage!

    Bonjour

    Je ne veux pas que l'on rajoute des choses dans la syntaxe de Java. Ca va devenir aussi difficile à lire que du C++ tout ça pour faire plaisir à ceux qui voudraient que Java ressemble à C#. Que Java reste Java, je demande à Sun de corriger les bugs, et de les corriger même sous Linux! Je voudrais tout simplement que Java 1.7 soit plus stable et plus rapide encore. Un des principaux avantages de Java est la syntaxe simple. Tout ce que je vois là ne fait que compliquer la lecture pour un gain minime voire nul alors arrêtez ce massacre!

  7. #67
    Expert Confirmé Sénior
    Avatar de djo.mos
    Inscrit en
    octobre 2004
    Messages
    4 673
    Détails du profil
    Informations forums :
    Inscription : octobre 2004
    Messages : 4 673
    Points : 7 849
    Points
    7 849

    Par défaut

    Bonjour,

    Citation Envoyé par gouessej Voir le message
    Bonjour

    Je ne veux pas que l'on rajoute des choses dans la syntaxe de Java. Ca va devenir aussi difficile à lire que du C++ tout ça pour faire plaisir à ceux qui voudraient que Java ressemble à C#. Que Java reste Java, je demande à Sun de corriger les bugs, et de les corriger même sous Linux! Je voudrais tout simplement que Java 1.7 soit plus stable et plus rapide encore. Un des principaux avantages de Java est la syntaxe simple. Tout ce que je vois là ne fait que compliquer la lecture pour un gain minime voire nul alors arrêtez ce massacre!

    Humm ... par ce que tu trouves que ça:
    Citation Envoyé par vbrabant Voir le message
    Aujourd'hui :
    Code :
    1
    2
    3
    Map<String, List<String>> 
      anagrams = new HashMap<String, List<String>>();
    Demain :
    Code :
    1
    2
    Map<String, List<String>> 
      anagrams = new HashMap<>();

    ça complique le langage
    J'aurais pu comprendre parfaitement ton point de vue lors de l'introduction des Generics en Java (surtout les Wildcards), mais là, il s'agit de simplifier ça, à moins que tu ne te trompes de post

  8. #68
    Invité régulier
    Inscrit en
    février 2008
    Messages
    4
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 4
    Points : 5
    Points
    5

    Par défaut

    Pour, la verbosité parfois excessive étant à mon avis l'un des handicaps de java la suppression de syntaxe redondante me semble un pas dans la bonne direction.

  9. #69
    Membre éclairé
    Inscrit en
    mai 2007
    Messages
    241
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 241
    Points : 300
    Points
    300

    Par défaut Pour, autre syntaxe possible.

    Mais j'ai hésité entre l'avantage de simplifier la lisibilité, et de complexifier la compréhension de la grammaire Java (de moins en moins accessible)

    Citation Envoyé par pseudocode Voir le message
    1. Par principe, je suis pour la séparation du type de la variable et du type de l'instance. J'irai meme jusqu'a imposer que le type d'une variable soit toujours une interface.

    2. Si le but c'est la lisibilité alors le gain est vraiment minime. Autant carrément supprimer le mot clé new et faire des allocations facon "C":

    Code java :
    1
    2
     
    HashMap<String, List<String>> anagrams;
    Dans l'idée de déclarer et instancier en une seule instruction j'avais aussi pensé à la syntaxe VB/LotusScript, qui a cependant ton inconvénient N°1: de ne pas utiliser d'interface:
    Code :
    1
    2
    3
    4
    5
    6
     
    // pseudo VB de LotusScript
    dim session as new Session()
     
    //transposé en Java Generics
    new HashMap<String,Person>(10) annuaire;
    De toutes façon, je trouve que c'est une peu du "sucre" syntaxique,
    est-ce qu'on ne pourrait pas carrément avoir un précompilateur comme en C, avec des des %Define et des typedefs, pour alléger les types trops longs à écrire?
    ça remplirait finalement la même fonction.

  10. #70
    Candidat au titre de Membre du Club
    Inscrit en
    mai 2007
    Messages
    15
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 15
    Points : 12
    Points
    12

    Par défaut

    Humm . Je suis contre cette évol du langage. L'intérêt est vraiment mineur et ça complexifie le langage (code plus lisible mais langage plus complexe).

    Pour moi, seules les évolutions vraiment utiles doivent être intégrées.

  11. #71
    Membre à l'essai
    Inscrit en
    novembre 2007
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 29

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

    Par défaut

    Je suis d'acord avec LeGritche, l'interet est mineur, alors ne compliquons pas.

  12. #72
    Membre régulier Avatar de fisico
    Inscrit en
    septembre 2003
    Messages
    98
    Détails du profil
    Informations forums :
    Inscription : septembre 2003
    Messages : 98
    Points : 70
    Points
    70

    Par défaut

    contre, l'apport de l'innovation ne change pas grand chose, même rien du tout. on a pris l'habitude de travailler ainsi.
    SCJP - SCWCD - SCBCD

  13. #73
    Invité régulier
    Inscrit en
    février 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 10
    Points : 5
    Points
    5

    Par défaut

    Je suis contre, tant qu'il y a la mécanique d'autocomplétion dans la majorité des IDEs, cette forme d'instantiation ne va ajouter que de difficultés au niveau de la lisibilité du code et le rendre moins compréhensible sur tout quand elle est loin de la déclaration de la référence.

  14. #74
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 336
    Points : 21 584
    Points
    21 584

    Par défaut

    Citation Envoyé par emile.coue Voir le message
    cette forme d'instantiation ne va ajouter que de difficultés au niveau de la lisibilité du code et le rendre moins compréhensible sur tout quand elle est loin de la déclaration de la référence.
    De la manière dont je l'ai compris, ce ne serait possible que dans le cas d'une instantiation en ligne... un peut comme pour les tableaux :

    Code :
    1
    2
    3
    4
    	int[] values = { 1, 2, 3, 4 }; // OK
     
    	values = { 1, 2, 3, 4 }; // ERREUR
    	values = new int[] { 1, 2, 3, 4 }; // OK
    a++

  15. #75
    Invité régulier
    Inscrit en
    février 2008
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 10
    Points : 5
    Points
    5

    Par défaut

    Bonjour adiGuba,

    De la manière dont je l'ai compris, ce ne serait possible que dans le cas d'une instantiation en ligne... un peut comme pour les tableaux :
    Dans ce cas, je vote pour. et ça sera pratique, et le code sera moins lourd, au niveau LECTURE.

    POUR

  16. #76
    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 : 23
    Points
    23

    Par défaut Contre trop d'implicite

    Je m'explique :
    L'instanciation ne suit la déclaration que dans des cas simples.
    S'ils sont séparés :
    Code :
    1
    2
    3
    4
     
            List<String> lst;
            (... code ...)
            lst = new ArrayList<>();
    on est obligé de retrouver la déclaration pour connaître le type de la liste (sauf avec un puissant IDE).
    Si quelqu'un doit se plonger dans du code qu'il n'a pas écrit, l'interprétation doit être sans ambiguïté.

    Il faut de toute façon conserver la syntaxe actuelle lorsque le type de l'instanciation est différent du type de la déclaration :
    Code :
    1
    2
     
            List<? extends MaSuperClass> lst = new ArrayList<MaClass>();

  17. #77
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 336
    Points : 21 584
    Points
    21 584

    Par défaut

    Citation Envoyé par fridobox Voir le message
    Je m'explique :
    L'instanciation ne suit la déclaration que dans des cas simples.
    S'ils sont séparés :
    Code :
    1
    2
    3
    4
     
            List<String> lst;
            (... code ...)
            lst = new ArrayList<>();
    Dans ce cas là la syntaxe ne serait sûrement pas possible.

    C'est un peu comme la syntaxe raccourci des tableaux, où l'on peut omettre le type du tableau :
    Code :
    1
    2
    3
    String[] array = { "a", "b", "c" };
    // A la place de :
    String[] array = new String[]{ "a", "b", "c" };
    Mais ce n'est possible que sur la déclaration. Si on affecte le tableau plus loin dans le code on est obligé d'utilité la syntaxe complète. Ainsi ceci ne compile pas :
    Code :
    1
    2
    3
    String[] array;
    // ...
    array  = { "a", "b", "c" };
    L'intérêt étant d'éviter de dupliquer l'information lorsque c'est possible (lorsqu'il y a affectation en ligne), tout en évitant les ambiguités...

    a++

  18. #78
    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 : 23
    Points
    23

    Par défaut ah

    Avec cette contrainte effectivement ça devient acceptable.

    Thanks

  19. #79
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 336
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 336
    Points : 21 584
    Points
    21 584

    Par défaut

    C'est fait : cette proposition a été intégré dans Java 7 sous le nom de "diamond syntax".

    Pour la petit histoire il s'agit de la première modification du langage de Java 7


    Pour plus d'info : Première modification du langage : Diamond syntax

    a++

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
  •