Publicité

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

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

    161 79,70%
  • Contre

    41 20,30%
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 28
  1. #1
    Expert Confirmé Sénior

    Inscrit en
    mai 2003
    Messages
    3 283
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 3 283
    Points : 9 776
    Points
    9 776

    Par défaut JDK 7: Proposition 2 : Créer facilement des Collections génériques vides

    Aujourd'hui :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    public <E> Set<E> emptySet() { … }
    void timeWaitsFor(Set<Man> people) { … }
    
    // * Won't compile!
    timeWaitsFor(Collections.emptySet());
    
    // OK
    timeWaitsFor(Collections.<Man>emptySet());
    Demain :

    Code :
    1
    2
    3
    4
    5
    6
    public <E> Set<E> emptySet() { … }
    void timeWaitsFor(Set<Man> people) { … }
    
    // OK
    timeWaitsFor(Collections.emptySet());
    Vincent Brabant

    Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.

  2. #2
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 262
    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 262
    Points : 19 321
    Points
    19 321

    Par défaut

    Oui : a noter que cela ne concerne pas seulement les Collections génériques mais n'importe quelles méthodes paramétrées

    a++

  3. #3
    Membre émérite
    Avatar de n!co
    Inscrit en
    février 2004
    Messages
    831
    Détails du profil
    Informations personnelles :
    Âge : 32

    Informations forums :
    Inscription : février 2004
    Messages : 831
    Points : 824
    Points
    824

    Par défaut

    J'ai voté OK, mais avec quelques intérrogations :
    1. Collections.emptySet() retourne une liste immuable donc pas de soucis en cas d'essaye d'ajout d'un element quelconque à cette liste ?
    2. Le "foreach" ne risque pas de poser problème ?
    Netbeans account : nico@share.java.net
    Merci de ne pas poser de questions techniques par MP

  4. #4
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Je trouve l'exemple mal formulé en fait. Je pense avoir compris que la fonction emptySet collée dans l'exemple du code provient en fait de Collections.

    Bref, je n'en ai jamais eu l'utilité, donc je ne me rend pas compte de la gène occasionné. Donc je ne vote pas

  5. #5
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 602
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 602
    Points : 6 228
    Points
    6 228

    Par défaut

    Bof, on pourrait utiliser quelque chose dans le genre
    Code :
    1
    2
     
    timeWaitsFor(new ArrayList<>());
    si le point 1 est OK

  6. #6
    Membre expérimenté Avatar de bassim
    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    février 2005
    Messages
    657
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : France

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

    Informations forums :
    Inscription : février 2005
    Messages : 657
    Points : 533
    Points
    533

    Par défaut

    J'ai pas voté parceque je ne vois pas vraiment l'utilité de ça !

    si quelqu'un a un exemple plus concret

  7. #7
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 262
    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 262
    Points : 19 321
    Points
    19 321

    Par défaut

    Citation Envoyé par bobuse Voir le message
    Bref, je n'en ai jamais eu l'utilité, donc je ne me rend pas compte de la gène occasionné. Donc je ne vote pas
    En fait le problème ne vient pas directement des Collections mais des Generics sur les méthodes. Mais ce problème ne se pose que dans très peu de cas très spécifique.

    Attention je parle bien des méthodes generics et non pas des classes generics, c'est à dire que le <T> est situé sur la méthode et non pas sur la classe. Par exemple si on prend la méthode Collections.sort() déclaré comme ceci :
    Code :
    public static <T extends Comparable<? super T>> void sort(List<T> list) {
    En fait lorsque on l'utilise on devrait toujours spécifié le type paramétré comme ceci :
    Code :
    1
    2
    3
    	List<String> list = ...
     
    	Collections.<String>sort(list);
    Heureusement le compilateur arrive à détecter le paramétrage par lui même et on n'est pas obligé de l'indiquer et continuer à écrire simplement :
    Code :
    Collections.sort(list);
    Comme list est de type List<String>, le compilateur arrive à déterminer que <T> correspond à String...


    En fait on n'est obligé d'indiquer le paramétrage qu'en cas d'ambigüité du compilateur, mais en règle général c'est assez rare...



    Le problème avec emptySet() (et les autres méthodes du même type), c'est que le compilateur ne peut se baser que sur le type de retour et qu'il est assez limité.

    emptySet() est déclaré de la manière suivante :
    Code :
    public static final <T> Set<T> emptySet() {
    Lorsque tu fais ceci il n'y a aucun problème :
    Code :
    Set<String> set = Collections.emptySet();
    Le compilateur arrive à déterminer que <T> vaut String
    selon le type de la variable qui va recevoir la valeur de retour.


    Par contre lorsque tu utilises une méthode, cela ne marche plus :
    Code :
    1
    2
    3
    public void method(Set<String> set) {
     ...
    }
    Code :
    method( Collections.emptySet() ); // BAD
    Ne marche pas car la valeur de retour n'est pas mise dans une variable, et que le compilateur ne peut donc pas la déterminer par ce moyen là.

    Pourtant dans ce cas le compilateur pourrait très bien utiliser le type du paramètre de la méthode pour déterminer le paramétrage à utiliser...


    Cette proposition consiste en fait à simplement faire en sorte que le compilateur utilise également le type des paramètres qui reçoivent le retour d'une méthode...


    C'est vraiment un cas très particulier assez anedoctique mais je pense que cela devrait être pris en compte...



    @ n!co
    1. La modficiation de emptySet() ou autre renvoi une exception
    2. foreach ne pose aucun problème (on n'y rentre tout simplement pas).

    a++

  8. #8
    Membre confirmé Avatar de bobuse
    Inscrit en
    janvier 2005
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : janvier 2005
    Messages : 229
    Points : 225
    Points
    225

    Par défaut

    Merci adibuga pour ces éclaircissements. Du coup, je vote pour, car ça ne bouleverse rien de manière inquiétante, et que ça apporte un petit plus. J'y repenserai si je tombe sur ce cas rare

  9. #9
    Membre Expert
    Avatar de xavlours
    Inscrit en
    février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 1 832
    Points : 2 153
    Points
    2 153

    Par défaut

    J'ai voté pour, parce que l'explication d'adiguba m'a fait mal à la tête et que je ne veux plus jamais avoir à me poser cette question
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  10. #10
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 262
    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 262
    Points : 19 321
    Points
    19 321

    Par défaut

    Citation Envoyé par xavlours Voir le message
    parce que l'explication d'adiguba m'a fait mal à la tête
    désolé

    a++

  11. #11
    Membre Expert
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    1 045
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 045
    Points : 1 367
    Points
    1 367

    Par défaut

    J'ai voté pour, parce que l'explication d'adiguba m'a fait mal à la tête et que je ne veux plus jamais avoir à me poser cette question
    Pareil.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  12. #12
    Membre du Club
    Profil pro
    Inscrit en
    juin 2003
    Messages
    190
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Sarthe (Pays de la Loire)

    Informations forums :
    Inscription : juin 2003
    Messages : 190
    Points : 62
    Points
    62

    Par défaut

    C'est du sucre syntaxique,il y a des évolutions qui sont plus importantes comme la facilitation de l'écriture des classes anonymes ou l'ajout des closures.

  13. #13
    Membre du Club
    Profil pro Nizar SAKLI
    Inscrit en
    novembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Nom : Nizar SAKLI
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2006
    Messages : 100
    Points : 60
    Points
    60

    Par défaut

    ma tête fais mâle de cette exemple.

  14. #14
    Membre du Club
    Inscrit en
    août 2002
    Messages
    67
    Détails du profil
    Informations forums :
    Inscription : août 2002
    Messages : 67
    Points : 53
    Points
    53

    Par défaut

    Je ne vois pas du tout l'intérêt, le type générique dépend de l'usage que l'on en fait?

    Encore une fois, ça n'encourage pas l'utilisation d'interfaces dans les déclarations génériques, et le code devient moins clair.

    Inutile, à mon avis, donc.

  15. #15
    Expert Confirmé Sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 262
    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 262
    Points : 19 321
    Points
    19 321

    Par défaut

    Heu... J'ai l'impression que mon explication a embrouillé tout le monde... je vais essayer de faire plus clair.




    Prenons une méthode paramétrée, par exemple :
    Code :
    1
    2
    3
    4
    5
    public class Tools {
    	public static <T> List<T> createList() {
    		return new ArrayList<T>();
    	}
    }
    Cette méthode permet de créer une ArrayList paramétrée, par exemple :
    Code :
    1
    2
    	List<Integer> integerList = Tools.createList();
    	List<String> stringList = Tools.createList();
    C'est ce qu'il est déjà possible de faire avec les Generics depuis Java 5. Mais comme createList() est une méthode paramétrée on devrait normalement spécifier le type paramétré à utiliser (le <T>), comme ceci :
    Code :
    1
    2
    	List<Integer> integerList = Tools.<Integer>createList();
    	List<String> stringList = Tools.<String>createList();
    Je suis sûr qu'une grande majorité ignore complètement l'existence de cette syntaxe (qui n'est d'ailleurs pas très agréable à l'oeil).

    En effet dans la plupart des cas elle est inutile puisque le compilateur arrive à détecter implicitement le type paramétré à utiliser :
    • Soit en regardant le type des paramètres de la méthodes (lorsqu'ils sont paramétrés).
    • Soit en regardant le type de la référence qui recevra la valeur de retour comme c'est le cas ici : createList() renvoi un List<T> qui est placé dans un List<Integer>, donc <T> est <Integer>.





    Seulement ce dernier cas est un peu limite car il ne vérifie pas la concordance des types si le retour est passé à une méthode, par exemple si j'ai une méthode comme ceci :
    Code :
    1
    2
    3
    	public void setList(List<String> list) {
    		// ...
    	}
    On ne peux pas faire ceci :
    Code :
    setList( Tools.createList() ); // Ne compile PAS
    On est obligé de spécifier le type :
    Code :
    setList( Tools.<String>createList() );
    Ceci tout simplement parce que le compilateur ne vas pas vérifier le type du paramètre de la méthode setList(). Il pourrait très bien le faire comme il le fait si on affecte le retour à un référence... mais non !


    Pour moi il ne s'agit pas vraiment d'une nouvelle proposition mais plutôt d'un oubli lors des spécifications des Generics... bref une correction de bug !




    a++

  16. #16
    Membre du Club
    Profil pro Nizar SAKLI
    Inscrit en
    novembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Nom : Nizar SAKLI
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : novembre 2006
    Messages : 100
    Points : 60
    Points
    60

    Par défaut

    merci adiGua de cette explication

  17. #17
    Rédacteur/Modérateur
    Avatar de pseudocode
    Homme Profil pro Xavier Philippeau
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    9 960
    Détails du profil
    Informations personnelles :
    Nom : Homme Xavier Philippeau
    Âge : 41
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 9 960
    Points : 15 081
    Points
    15 081

    Par défaut

    J'ai voté pour. D'ailleurs je pensais que cette fonctionnalité etait déja implémentée depuis java 5.

    Comme dit adiGuba, ca ressemble plus a un "oubli" qu'a une évolution.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  18. #18
    Membre du Club
    Inscrit en
    août 2002
    Messages
    67
    Détails du profil
    Informations forums :
    Inscription : août 2002
    Messages : 67
    Points : 53
    Points
    53

    Par défaut

    Citation Envoyé par adiGuba Voir le message
    Heu... J'ai l'impression que mon explication a embrouillé tout le monde... je vais essayer de faire plus clair.
    [...]
    On ne peux pas faire ceci :
    Code :
    setList( Tools.createList() ); // Ne compile PAS
    On est obligé de spécifier le type :
    Code :
    setList( Tools.<String>createList() );
    Merci, c'est en effet très clair. Mais je ne vois pas ce qui est si gênant, car cela permet au développeur de savoir explicitement quel type transite.

    D'autant que si on utilise les génériques, on pourrait tout aussi bien avoir la méthode
    Code :
    1
    2
    3
    public void setList(List<String> list) {
    		// ...
    	}
    générique également :
    Code :
    1
    2
    3
    public void setList(List<T> list) {
    		// ...
    	}
    Par ailleurs, si on utilise des types avec héritage, ou des types implémentant des interfaces, il faut bien que l'on spécifie explicitement le type, non?
    Nos 2 types implémentants Vehicule:
    Code :
    1
    2
    3
     
    Class Voiture implements Vehicule{[...]}
    Class Charette implements Vehicule{[...]}
    Notre méthode de réception qui ne connait pas l'implémentation du véhicule:
    Code :
    1
    2
     
    public void setVehicule(<Vehicule> v) {}
    Une classe SingletonFactory qui nous retourne une instance unique de la classe spécifiée :
    Code :
    public <T> getInstance() {[...]}
    et l'utilisation:
    Code :
    1
    2
     
    setVehicule( SingletonFactory.<Charette>getInstance() );
    Je ne pratique pas depuis longtemps le Java5 et les génériques, donc veuillez m'excuser les erreurs de syntaxe, je pense que ça ne change pas grand chose à la logique.

    J'attends vos réactions et corrections syntaxiques si nécessaire.

  19. #19
    Membre Expert
    Avatar de xavlours
    Inscrit en
    février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : février 2004
    Messages : 1 832
    Points : 2 153
    Points
    2 153

    Par défaut

    Dans ton cas, il serait de toutes façons nécessaire de garder la précision du type, puisque la méthode getInstance peut retourner n'importe quel type. Par contre, si tu précises :
    Code :
    public <T extends Vehicule> T getInstance() {...}
    Alors le typage explicite de la méthode getInstance est inutile lors de l'appel de setVehicule.
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  20. #20
    Membre confirmé
    Étudiant
    Inscrit en
    juillet 2004
    Messages
    230
    Détails du profil
    Informations personnelles :
    Âge : 24

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juillet 2004
    Messages : 230
    Points : 200
    Points
    200

    Par défaut

    mouais bof je prefere que ca reste encore un peu verbeux .... c'est juste un petit plus

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
  •