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
Cordialement,
elitost(Eric Reboisson)
SpringSource Certified Spring Professional
Certifié SCWCD J2EE 5.0
Certifié SCJP J2SE 5.0
Certifié ITIL Foundation
Responsable : FAQ Maven 2 , FAQ SCM
Autres : Site web Developpez , Mon site personnel , Mon CV
Twitter : Suivez moi sur Twitter
Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.
Ceci serait mieux :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
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 : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Map<String, List<String>> anagrams = new HashMap();
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
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), 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 : Sélectionner tout - Visualiser dans une fenêtre à part
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne le savait pas et qui l'a fait. Marcel PAGNOL
On ne savait pas que c'était impossible, alors on l'a fait. John Fitzgerald KENNEDY.
L'inexpérience est ce qui permet à la jeunesse d'accomplir ce que la vieillesse sait impossible. Paul (Tristant) BERNARD
La meilleure façon de prédire l'avenir, c'est de l'inventer.
Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
De la bonne manière de poser une question (et de répondre).
Je ne fais pas de service par MP. Merci (...de lire les règles...).
Ma page dvp.com
Nous sommes tous semblables, alors acceptons nos différences !
--------------------------------------------------------------
Liens : Blog | Page DVP | Twitter
Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
Critiques : Apache Maven
POUR, même si le "<>" me paraît inutile également
" Jag blev dömd för fildelning och allt jag fick var en sketen t-shirt. " (tankafritt.nu)
PAS DE REPONSE PAR MESSAGE PRIVE ! Penser au bouton Résolu en bas de la discussion...
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 : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Map<String, List<String>> anagrams = new HashMap();
Je pense qu'il ne faut pas trop en enlever non plus hein... Le fait de mettre "<>" indique clairement à l'oeil que ce n'est pas une "simple HashMap" qui est instanciée.
Et ça ferait quoi ce code là ?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Map anagrams = (Map<String, List<String>>)new HashMap<>();
Et un d'plus en moins !
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.
Comment ça ? La réponse à ton problème n'est ni dans la faq, ni dans les tutos, ni dans sources ??? Etonnant...
De la bonne manière de poser une question (et de répondre).
Je ne fais pas de service par MP. Merci (...de lire les règles...).
Ma page dvp.com
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 : Sélectionner tout - Visualiser dans une fenêtre à part
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 :
Cela ne marche pas car les types ne correspondent pas, et c'est logique car tu pourrais faire ceci :
Code : Sélectionner tout - Visualiser dans une fenêtre à part Map<String,Vehicule> map = new HashMap<String,Camion>();
Tu ajoutes une voiture dans une liste de camion
Code : Sélectionner tout - Visualiser dans une fenêtre à part 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 : Sélectionner tout - Visualiser dans une fenêtre à part 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 !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.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager