JDK 7: Proposition 1 : Constructeurs simplifiés pour la généricité -> Intégrée [Débat]

[bobuse]

J'ai pas tout suivi, mais de toutes façons les Vector c'est mal

[elitost]

Egalement pour, et pour les mêmes raisons citées précedemment, redondance d'information, mais pour garder les 2 notations

[bouye]

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

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

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.

[nicorama]

Envoyé par bobuse

J'ai pas tout suivi, mais de toutes façons les Vector c'est mal

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.

[jibbi]

Envoyé par bulbo

Même si pour la compatibilité, l'autre écriture est bien nécessaire, je n'arrive pas a voir un cas ou cela aurait un intérêt.

Tu arriverais a nous filer un exemple ?

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:

Code :

1
2
3
 
List<String> list = new ArrayList<>(5); 
// pas de problème c'est une list de String

Et si l'initialisation de la list se fait au milieu du code:

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.

Donc pour une initialisation au moment de la déclaration, je suis pour la nouvelle syntaxe. Dans le cas contraire, utiliser la forme actuelle.

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

[benwit]

Je vote pour également.

Envoyé par adiGuba

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).

a++

[natha]

Voté "pour" pour toutes les raisons évoquées.

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Je me pose la même question. Aucun intérêt de toute façon.

[romaintaz]

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

Ceci serait mieux :

Code :

En effet, c'est clair que je ne vois pas l'intérêt d'ajouter le <> ...

[g_rare]

POUR, même si le "<>" me paraît inutile également

[Alec6]

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à.

[nicorama]

Code :

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

Ce code marche très bien aujourd'hui, en tout cas sur mon PC.... Que faut t-il changer ?

[ludosoft]

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

Ceci serait mieux :

Code :

Pour le reste, l'information type est deja convoye dans la partie gauche de l'affectation.

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 :

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

[Alec6]

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.

[natha]

Envoyé par nicorama

Code :

Ce code marche très bien aujourd'hui, en tout cas sur mon PC.... Que faut t-il changer ?

C'est parce que tu as désactivé les warnings checked/unchecked... alors évidemment...

[xavlours]

J'ai voté pour, mais j'ai peur que ça complique encore la prise en main des generics.

Envoyé par bulbo

Même si pour la compatibilité, l'autre écriture est bien nécessaire, je n'arrive pas a voir un cas ou cela aurait un intérêt.
Tu arriverais a nous filer un exemple ?

Code :

1
2
Map<String, ? extends Collection<? extends Image>> map;
map = new HashMap<String, Set<BufferedImage>>();

Il faut préciser le type de la Map, ce qui est normal, mais qui n'est pas évident à comprendre au début.

Mais je vote pour.

[adiGuba]

Envoyé par nicorama

Code :

Ce code marche très bien aujourd'hui, en tout cas sur mon PC.... Que faut t-il changer ?

Envoyé par natha

C'est parce que tu as désactivé les warnings checked/unchecked... alors évidemment...

+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...

Envoyé par Alec6

Milles excuses c'est vrai que les générics n'acceptent pas l'heritage et on ne peut pas faire de polymorphisme avec.

Oui on peut, mais pas comme cela :

Code :

Map<String,Vehicule> map = new HashMap<String,Camion>();

Cela ne marche pas car les types ne correspondent pas, et c'est logique car tu pourrais faire ceci :

Code :

map.put("Clio", new Voiture());

Tu ajoutes une voiture dans une liste de camion


En fait il faut faire ceci :

Code :

Map<String,? extends Vehicule> map = new HashMap<String,Camion>();

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


a++

[jproto]

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.

[cysboy]

J' ai voté pour !

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).

Il a tout dit !

[pierreact]

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...

[Uther]

Je suis également pour et ne vois pas non plus l'interet du <>, vu que la généricité est seulement un sucre syntaxique.