Discussion :

[adiGuba]

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

Dans ce cas il faudrait généraliser cette ecriture pour toutes les méthodes paramétrées... Perso cela ne me branche pas trop d'écrire quelque chose du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	List<String> list = ...
	// ...
 
	Collections.<String>sort(list);

Les Generics sont là pour supprimer les cast mais si pour cela il faut spécifier le typage là où il n'y en avait pas besoin c'est pas top...


a++

[daedric]

certes mais pour un mec qui lit ton code c'est quand meme plus clair quant au type d'objet contenu

enfin moi disons que ca m'est un peu egale si ca passe ou pas ce changement

[Uther]

Après l'explication d'AdiGuba, ca me parait clairement aussi comme un oubli à corriger.

J'étais tenté de dire non au début mais si spécifier le type n'est pas nécéssaire pour une affectation, il n'y a pas de raison pour que ça le soit pour un passage en paramètre d'une fonction.

[kisame]

Ca y est ! j'ai compris. Merci adibuga

pour.

[gpaco974]

je vote oui, et AdiGuba pour ton explication à le mérite de clarifier l'apport de cette proposition.

[deltree]

Bonjour,
j'avais préparé une réponse un peu trop longue et pas très claire que je me suis donc abstenu de poster.
Mais pour faire court: Est-ce que ça ne choque personne de "spécifier" le type générique par son type de destination?
ça me semble contraire à la forme que prend la compilation: d'abord les arguments indépendamment, puis ensuite la méthode appelante.

si on veut pousser plus loin, on pourrait avoir:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
List<String> lMyList;
lMyList = Tools.createList() ); // Ne compile PAS

Au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
List<String> lMyList;
lMyList = Tools.<String>createList() ;

C'est presque le même cas sauf qu'on passe par une variable, on est censé savoir que createListe est un type List<String> parce qu'on l'affecte à un type List<String> et que c'est le retour qu'on attend. mais "Tools.createList() " pris indépendamment ne signifie rien.

Moi je ne suis pas pour parce que ça embrouille l'esprit, ça me semble moins carré par rapport au choix actuels:
la signature d'une méthode prend en compte son nom et le type des arguments, mais pas le type du retour.

edit: merci néanmoins à tous ceux qui ont permis de rendre simple cette proposition, qui n'avait pas l'air simple au départ

[gexian]

Pour, parce que je ne connaissait même pas la syntaxe Classe.<Type>methodGeneric() .

[fridobox]

Il est vrai que je n'ai jamais eu à faire à ce problème mais je suis pour car, de ce que j'en ai compris, c'est déjà à moitié implémenté dans le compilateur.
Cela permet d'avoir une syntaxe qui fait le maximum abstraction des génériques.