Sous-typer une valeur de retour de méthode générique

Bonjour,

Dans cet example

Code:

---

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

interface underType { static interface A<B> {} Object f(); A<?> g(); <N extends A<?>> N h(); static interface Child extends underType { @Override String f(); @Override A<String> g(); @Override <N extends A<String>> N h(); // //@Override <N extends A<? extends String>> N h(); } }

---

Je n'arrive pas à surcharger h() dans Child ("The method h() of type underType.Child must override or implement a supertype method"), alors que <N extends A<String>> et <N extends A<? extends String>> sont des sous-types de <N extends A<?>>.
Savez vous comment faire?

Merci d'avance

Salut,

Citation:

---

Envoyé par shaiHulud

<N extends A<String>> et <N extends A<? extends String>> sont des sous-types de <N extends A<?>>

---

Je vois ce que tu veux faire, même si le polymorphisme permet d'avoir un type de retour covariant (ps: depuis Java 5), cela ne fonctionne qu'avec les classes simples, pas les génériques Java. Pour tester, sans aller jusqu'au wildcard, remplace le contenu du générique parent par N extends Object et celle du child par N extends String, String hérite d'Object et pourtant le compilateur t'empêche de compiler car ce dernier génère la même signature pour les deux méthodes mais l'un ne redéfinit pas l'autre selon lui. Tu es dans un cas de limitation du type erasure.

J'avais écrit un article sur la limitations des génériques en Java, si ça t'intéresse...


A+

C'est bien ce que je craignais.
Merci bcp Gugelhupf !

Une telle chose est impossible certes.

Mais pour information ça n'a rien à voir avec le type erasure, puisque après type erase toutes les méthodes h() renvoient simplement A, donc ont toutes la même signature.

C'est avant le type erasure qu'elles n'ont pas la même signature.

Quand une méthode est générique, c'est-à-dire qu'elle a une déclaration de types paramétrés, alors toute méthode qui cherche à la redéfinir doit proposer la même déclaration de types paramétrés, sans aucune différence, un point c'est tout. Une variation et les signatures deviennent incompatibles.

Dans l'exemple proposé ici on ne comprend pas pourquoi, ça a l'air d'une limitation abusive et sans intérêt, puisque le type paramétré, N, est le type de retour des méthodes et donc une redéfinition de méthode devrait pouvoir donner comme type de retour un sous-type du type proposé avant redéfinition.

C'est ce qu'on peut se dire face à cet exemple, nous pauvres humains, mais c'est parce qu'on oublie un peu vite qu'un type paramétré de méthode qui ne sert que comme type de retour, ça n'a aucune utilité. L'outil est là pour faire du type safe, et à la place on fait quelque chose qui est clairement le contraire du type safe.

Dans le monde réel N devrait apparaître ailleurs, comme par exemple :

Code:

---

<N extends A<?>> N h(N param);

---

Et là d'un seul coup c'est pas la même, si on s'amuse à remplacer <N extends A<?>> par quoi que ce soit d'autre ce n'est évidemment pas acceptable dans une redéfinition.

Et le compilateur, lui, c'est tout ce qui l'intéresse : modifier les paramètres génériques, ce n'est pas acceptable pour une redéfinition. Le fait que cela aurait pu marcher dans la mesure où il se trouve par hasard que les paramètres génériques ne sont utilisés que comme type de retour, ce n'est pas son problème. De toute façon c'est un abus de syntaxe au départ.

Merci beaucoup pour les détails thelvin, c'est très clair.

Peux-tu détailler un peu ta remarque stp ?

Citation:

---

un type paramétré de méthode qui ne sert que comme type de retour, ça n'a aucune utilité

---

Pas vraiment parce qu'en fait, il y a un intérêt. Mais, ce n'est pas celui qui était prévu par le mécanisme des génériques.

Code:

---

1 2 3

interface DonneurDObjet { <T> T donneUnObjet(); }

---

Ça s'utilisera un peu comme ça :

Code:

---

1 2 3 4 5

DonneurDObjet donneur = recupererUnDonneur();   // ...   LocalDate date = donneur.donneUnObjet();

---

Et à aucun moment le système ne sait que l'objet à donner est de type LocalDate. On compte juste sur le fait que l'appel à recupererUnDonneur() va nous filer un donneur qui donne des LocalDate, parce que le programmeur s'est arrangé pour que ce soit ça qu'on obtienne.

Si on n'utilisait pas les paramètres, on aurait ça :

Code:

---

1 2 3

interface DonneurDObjet { Object donneUnObjet(); }

---

Code:

---

1 2 3 4 5

DonneurDObjet donneur = recupererUnDonneur();   // ...   LocalDate date = (LocalDate) donneur.donneUnObjet();

---

Un simple cast qui s'assure que l'objet donné est bien du type voulu.
Et c'est exactement ce que fait le code générique. Un simple cast qu'on a pas besoin de taper.

C'est à ça que sert le code : économiser de taper un cast qui sera fait automatiquement. Puisque de toute façon le cast est inévitable pour assurer le typage.

Ce n'est pas grand-chose, et ce n'est pas là que réside l'intérêt des génériques. Le système n'est donc pas fait pour s'adapter à ça.

Et en plus ça a un prix : il devient possible d'écrire quelque chose comme :

Code:

---

1 2 3 4

<T> void ajouterDansListe(List<T> liste) { T nouveau = donneur.donneUnObjet(); liste.add(nouveau); }

---

Et là c'est le drame : pas de cast pour s'assurer que l'objet donné est bien du même type que la List. Nous avons perdu la sûreté du type. Tout ça parce que nous avons utilisé un type paramétré de méthode uniquement comme valeur de retour de cette méthode.

Tout cela était une mauvaise idée, même si elle a l'air pratique de temps en temps.

Je pense que ton exemple (sans wildcard) aurait pu fonctionner en C#, voici un test (lien) que j'ai effectué :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

using System;   public class Test { public static void Main() { // your code goes here }   interface Parent {}   interface Child : Parent {}   interface A { T h<T>() where T : Parent; }   interface B : A { T h<T>() where T : Child; // Voir ICI } }

---

Merci beaucoup à tous les 2 pour les précisions !