J'ai pas tout suivi, mais de toutes façons les Vector c'est mal
J'ai pas tout suivi, mais de toutes façons les Vector c'est mal
Egalement pour, et pour les mêmes raisons citées précedemment, redondance d'information, mais pour garder les 2 notations
Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.
Ceci serait mieux :Code:
1
2 Map<String, List<String>> anagrams = new HashMap<>();
Pour le reste, l'information type est deja convoye dans la partie gauche de l'affectation.Code:
1
2 Map<String, List<String>> anagrams = new HashMap();
:mouarf:Ouais je sais que c'est mal, mais tant que j'ai pas compris à 100% les tenants et aboutissant des synchronized quand il y a des threads de partout (et ya du boulot:aie:), je met tout en Vector. Je changerais le jour où j'aurais tout compris.
En terme de performance, ca change quedalle pour mon projet, comparé aux temps des accès clients/serveur.
Un des avantages avec les generic c'est qu'on peut connaître le type que contient une Collection au premier coup d'oeil.
la nouvelle forme présenté permet cela à la déclaration de la Collection:
Et si l'initialisation de la list se fait au milieu du code:Code:
1
2
3 List<String> list = new ArrayList<>(5); // pas de problème c'est une list de String
Donc pour une initialisation au moment de la déclaration, je suis pour la nouvelle syntaxe. Dans le cas contraire, utiliser la forme actuelle.Code:
1
2
3
4
5
6
7
8 List<String> list; // déclaration [...] list = new ArrayList<>(5); // ici, faut aller voir la déclaration ou étudier //le code pour connaître le type de la liste.
Pourrait-on se fier aux "bonnes pratiques" du programmeur pour respecter cela ? j'en doute, j'apprécierais un warning.
D'accord je suis peut-être un peu pointilleux, mais je ne pense qu'à vous les correcteurs de Developpez.com :)
POUR, même si le "<>" me paraît inutile également ;)
Je peut etre pas tout compris cependant.
Il y aurait pas une différence de typage et d'héritage entre l'objet construit et la variable porteuse, dans l'idée du polymorphisme.
Map<String,Vehicule> map;
map=new Map<String,Camion>();
map=new Map<String,Voiture>();
Camion, et Voiture extends Vehicule;
et j'ai une méthode do(Map<String,Vehicule>);
Si j'écris rien, j'ai implicitement, Map<Object,Object> map=new Map<Object,Object>();
Voilà voilà.
Ce code marche très bien aujourd'hui, en tout cas sur mon PC.... Que faut t-il changer ?Code:
1
2 Map<String, List<String>> anagrams = new HashMap();
Milles excuses c'est vrai que les générics n'acceptent pas l'heritage et on ne peut pas faire de polymorphisme avec.
Snif.
J'ai voté pour, mais j'ai peur que ça complique encore la prise en main des generics.Il faut préciser le type de la Map, ce qui est normal, mais qui n'est pas évident à comprendre au début.Code:
1
2 Map<String, ? extends Collection<? extends Image>> map; map = new HashMap<String, Set<BufferedImage>>();
Mais je vote pour.
+1
Actuellement ce code génère un warning, qui est un peu inutile dans ce cas précis. Pourtant la solution de désactiver les warnings checked/unchecked n'en est pas une car il y a d'autre warning qu'il faut conserver car il révèle un problème réel.
Pour moi cette proposition est une correction d'une "erreur" des Generics de Java 5.0 qui aboutissent à une syntaxe inutilement lourde...
Oui on peut, mais pas comme cela :
:arrow: Cela ne marche pas car les types ne correspondent pas, et c'est logique car tu pourrais faire ceci :Code:Map<String,Vehicule> map = new HashMap<String,Camion>();
:arrow: Tu ajoutes une voiture dans une liste de camion :aie:Code:map.put("Clio", new Voiture());
En fait il faut faire ceci :
Et avec cette syntaxe certaine méthode te sont interdite car tu ne connais pas le type précis de Vehicule. ainsi tu ne peut pas faire de put() mais tu peux consulter les valeurs comme s'il s'agissait de Vehicule ;)Code:Map<String,? extends Vehicule> map = new HashMap<String,Camion>();
a++
Je vote pour, tant que la version actuelle continue d’être exploitable.
Dans certaines situations déjà citées, je la trouve plus claire.
Par contre, je dois partager le scepticisme de mes camarades vis-à-vis de l’utilité du <>.
Lorsque l’instanciation est directement rattachée à la déclaration, il n’y a pour moi pas de risque de méprise.
Lorsqu’elles sont séparées, je me rabattrai de toute façon sur la notation actuelle.
J' ai voté pour !
Il a tout dit !Citation:
agiGuba à écrit :
Oui pour moi : cela permet d'éviter une répétition inutile...
Bien sûr quoi qu'il arrive la première syntaxe sera toujours valide (rien que pour assurer la compatibilité ascendante).
Je suis pour et souhaite aussi que les deux syntaxes restent disponible...
Si cela est _impossible_... (Pas de raison, mais...) J'accepte quand meme, vu que le generique et l'instance ne sont que repetition de toutes facons...
Je suis également pour et ne vois pas non plus l'interet du <>, vu que la généricité est seulement un sucre syntaxique.