Discussion :

[vbrabant]

Aujourd'hui :

Code :

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

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 :

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

1
2
3
4
5
6
public <E> Set<E> emptySet() { … }
void timeWaitsFor(Set<Man> people) { … }

// OK
timeWaitsFor(Collections.emptySet());

[adiGuba]

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

a++

[n!co]

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 ?

[bobuse]

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

[OButterlin]

Bof, on pourrait utiliser quelque chose dans le genre

Code :

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

1
2
 
timeWaitsFor(new ArrayList<>());

si le point 1 est OK

[bassim]

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

si quelqu'un a un exemple plus concret

[adiGuba]

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 :

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

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 :

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

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 :

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

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 :

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

public static final <T> Set<T> emptySet() {

Lorsque tu fais ceci il n'y a aucun problème :

Code :

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

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 :

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

1
2
3
public void method(Set<String> set) {
 ...
}

Code :

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

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

[bobuse]

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

[xavlours]

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

[adiGuba]

parce que l'explication d'adiguba m'a fait mal à la tête

désolé

a++

[Patriarch24]

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.

[super_navide]

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.

[sakli]

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

[Invité]

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.

[adiGuba]

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 :

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

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 :

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

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 :

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

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 :

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

1
2
3
	public void setList(List<String> list) {
		// ...
	}

On ne peux pas faire ceci :

Code :

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

setList( Tools.createList() ); // Ne compile PAS

On est obligé de spécifier le type :

Code :

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

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

[sakli]

merci adiGua de cette explication

[pseudocode]

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.

[Invité]

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 :

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

setList( Tools.createList() ); // Ne compile PAS

On est obligé de spécifier le type :

Code :

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

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 :

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

1
2
3
public void setList(List<String> list) {
		// ...
	}

générique également :

Code :

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

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 :

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

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 :

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

1
2
 
public void setVehicule(<Vehicule> v) {}

Une classe SingletonFactory qui nous retourne une instance unique de la classe spécifiée :

Code :

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

public <T> getInstance() {[...]}

et l'utilisation:

Code :

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

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.

[xavlours]

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 :

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

public <T extends Vehicule> T getInstance() {...}

Alors le typage explicite de la méthode getInstance est inutile lors de l'appel de setVehicule.

[daedric]

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