generics et retour de type implementé

slt

le titre n'est pas très parlant mais je vais tenter d'expliquer le cas

j'ai une classe A qui utilise un generic et qui propose une methode duplicate

Code:

---

1 2 3 4 5

public interface A {     public <T extends A>T duplicate();

---

j'ai une classe B qui implemente A

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class B implements A {     public B duplicate() {   B b = new B(); return b;   }   }

---

pourtant j'ai un warn de compile sur "public B duplicate()" car il me dit que
"Type safety: The return type B for duplicate() from the type B needs unchecked conversion to conform to T from the type A"

pourtant B est bien de type A par héritage

comprend pas

une idée ?

Oui, cela ne va pas du tout.

Imagine que tu aies la déclaration suivante :

Code:

---

1 2	public class C extends A {...}

---

... tu pourrais très bien écrire, avec ta déclaration de duplicate :

Code:

---

1 2 3

B b = new B(); C c = b.duplicate();

---

... ce qui serait légal à la compilation, mais de façon tout à fait erronée. On peut donc bien dire que la déclaration <T extends A> n'est pas équivalente à la déclaration class B extends A, aussi bizarre que cela puisse paraitre.

D'une façon générale, le extends d'héritage ne signifie pas la même chose que le extends des génériques, même si la relation qu'il exprime entre les deux parties est la même (ou quasiment la même).

Il faut utiliser super et non pas extends dans le generic pour symboliser la relation que tu veux.

Bulbo ;)

Salut,

Citation:

---

Envoyé par bulbo

Il faut utiliser super et non pas extends dans le generic pour symboliser la relation que tu veux.

---

Non non c'est bien extends !

En fait si je comprend bien austin P. veut faire référence au type courant. Ici cela ne peut pas marcher car les generics ne s'applique qu'à la méthode et dépendent donc de son appel et non pas du type courant.


Il s'agit du pattern "SelfType" qui peut être défini comme cela avec les Generics :

Code:

---

1 2 3 4 5

interface A<THIS extends A<THIS>> {   public THIS duplicate();   }

---

Le type THIS représente le type courant, et le extends A<THIS> permet d'être sûr qu'il s'utilise correctement :

Code:

---

1 2 3 4 5 6

class B implements A<B> {   public B duplicate() { return new B(); } }

---

Par contre il y a un gros défaut c'est que cela ne fonctionne qu'à un seul niveau d'héritage. Un sous-type de B peut très bien déclarer renvoyer un objet de type B et non pas son propre type...



A noter qu'il y a une RFE sur le sujet : http://bugs.sun.com/bugdatabase/view...bug_id=6479372

Ce qui permettrait d'utiliser les self-types pour les valeurs de retour :
[code]

Code:

---

1 2 3 4 5

interface A {   public this duplicate();   }

---

Ce qui obligerait toutes les classes implémentant l'interface à renvoyer leurs propres types...

Mais rien d'officiel pour le moment...

a++

Citation:

---

Envoyé par bulbo

Il faut utiliser super et non pas extends dans le generic pour symboliser la relation que tu veux.

---

euh c'est a dire ?

Citation:

---

Envoyé par adiGuba

Salut,



Non non c'est bien extends !

En fait si je comprend bien austin P. veut faire référence au type courant.

---

KORREQ :D

Citation:

---

Envoyé par adiGuba

Ici cela ne peut pas marcher car les generics ne s'applique qu'à la méthode et dépendent donc de son appel et non pas du type courant.

---

et M....

Citation:

---

Envoyé par adiGuba

Par contre il y a un gros défaut c'est que cela ne fonctionne qu'à un seul niveau d'héritage. Un sous-type de B peut très bien déclarer renvoyer un objet de type B et non pas son propre type...

---

c'est bien là ou j'en était arrivé après plusieurs tests
dommage

Citation:

---

Envoyé par adiGuba

Ce qui obligerait toutes les classes implémentant l'interface à renvoyer leurs propres types...

Mais rien d'officiel pour le moment...

---

c'est bien dommage parske réellement utile

Et j'ajouterais à toutes ces excellentes explications que, en l'état, je ne vois absolument pas à quoi servirait la construction de austin P., même dans l'hypothèse où elle voudrait dire quelque chose et où elle marcherait ?...

Une solution plus simple, vu le nom et je suppose la fonction de la methode, aurait ete de faire un copy constructor non ?

Code:

---

1 2 3 4

public B(B aB) { //.. creation d'un nouveau B, copie conforme du premier }

---

bon on peut pas forcer ca dans une interface c'est le seul inconvenient.

Bulbo ;)

Citation:

---

Envoyé par gifffftane

Et j'ajouterais à toutes ces excellentes explications que, en l'état, je ne vois absolument pas à quoi servirait la construction de austin P., même dans l'hypothèse où elle voudrait dire quelque chose et où elle marcherait ?...

---

Cela peut servir par exemple à renvoyer le type courant bien typé sans forcément le redéfinir dans les classe fille.

Par exemple si tu as une classe comme ceci :

Code:

---

1 2 3 4 5 6

public class A { public A append(String s) { // code du append() return this; } }

---

Le fait de retourner this permet d'enchainer les appels :

Code:

---

1 2	A a = new A(); a.append("a").append("b").append("c").append("d");

---

Maintenant si tu fait une sous-classe :

Code:

---

1 2 3 4 5 6

public class B extends A{ public B insert(String s) { // code du insert() return this; } }

---

Tu ne peux pas cumuler les deux :

Code:

---

1 2	B a = new B(); a.append("a").insert("b"); // IMPOSSIBLE

---

En effet comme append() retourne un type A tu ne peux pas appeler insert().



Une autre solution serait d'utiliser la covariance et de redéfinir la méthode :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

public class B extends A{ public B insert(String s) { // code du insert() return this; }   @Overrides public B append(String s) { super.append(s); // on se contente d'appeler la classe parente return this; }   }

---

Mais lorsqu'on a beaucoup de méthode cela devient fastidieux et surtout inutile. Avec un "self-type" cela serait automatique...



A noter que cette "astuce" est utilisé les classes StringBuffer et StringBuilder, qui héritent chacune leurs méthodes d'une classe AbstractStringBuilder invisible (package-view).

a++

Je comprends tout à fait et parfaitement, sauf que la question portait au départ sur les génériques, et que, pour montrer une utilité... tu n'utilises pas le moindre générique. CQFD, donc ?

Je pense que c'était un des points obscurs de la question, qui utilisait des conventions pour les génériques sur des classes et vice versa. Peut être était-ce aussi un point obscur dans la tête de notre questionneur, d'ailleurs ?... Peut être y voit-il un peu plus clair maintenant ?

Citation:

---

Envoyé par gifffftane

Je comprends tout à fait et parfaitement, sauf que la question portait au départ sur les génériques, et que, pour montrer une utilité... tu n'utilises pas le moindre générique. CQFD, donc ?

Je pense que c'était un des points obscurs de la question, qui utilisait des conventions pour les génériques sur des classes et vice versa. Peut être était-ce aussi un point obscur dans la tête de notre questionneur, d'ailleurs ?... Peut être y voit-il un peu plus clair maintenant ?

---

peut import les génériques : ils ne sont qu'un moyen pour arriver à la solution d'ailleurs <mode leche>très bien expliqué par notre adiguba national</mode leche>:mrgreen:

vivement le self type