Discussion :

[scheme]

Bonjour à tous

J'ai une classe qui gère des collections. J'ai plusieurs attributs de type ArrayList<T> ou T prendre plusieurs formes différentes. J'aimerais les gérer de la même manière, or je me heurte à des name clash à cause du Type Erasure de Java, c'est-à-dire que le compilateur ne regarde que le type du container pour déterminer la signature des méthodes.

Donc ces 3 méthodes ont la même signature:

public void set(ArrayList<Double> v) { };
public void set(ArrayList<ArrayList<Double>> vv) { };
public void set(ArrayList<ArrayList<ArrayList>>> vvv) { };

J'aimerais éviter d'utiliser des noms différents pour ces méthodes car j'utilise ces collections de manière dynamiques, c'est à dire que l'utilisateur ne sait pas quelle collection il utilise à un moment T.

Donc ma question est la suivante: connaissez-vous une manière de contourner ce Type Erasure et le name clash pour arriver à mes fins ?

Merci d'avance

[professeur shadoko]

est ce possible dans ton contexte???

Code :

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

1
2
3
 
class ArrayListDouble extends ArrayList<Double> {
}

????
edit: j'ai pas compris pourquoi tu tiens à faire de la surcharge de set ...

[scheme]

Disons que je gère un arbre à 3 niveaux pour stocker des données, et que je peux manipuler de façon transparente pour l'utilisateur un ArrayList<Double> et un ArrayList<ArrayList<ArrayList<Double>>>, ce fonctionnement est assez lourd et imposé, il a été codé à l'origine pour manipuler les données avec beaucoup de flexibilité, grace à des méthodes massivement overloadées et des arguments optionnels. Sauf que c'était en C++, et que la en Java ça m'apporte plus de complexité qu'autre chose en le recodant.

C'est une grosse classe et ça m'embête de refaire la conception, c'est pour ça que je cherche une alternative. La tienne est intéressante, je vais me pencher sur la question

[Rei Ichido]

J'aimerais éviter d'utiliser des noms différents pour ces méthodes car j'utilise ces collections de manière dynamiques, c'est à dire que l'utilisateur ne sait pas quelle collection il utilise à un moment T.

Ce qui revient à dire que de toute façon, tu ne pourras pas contourner la difficulté, si ce n'est en faisant du instanceof puis l'appel de méthodes à des signatures (et éventuellement des noms) différentes. Il n'y a pas de "polymorphisme sur les paramètres", justement parce que c'est résolu à la compilation.

Dans ce contexte, si tu peux définir tes listes comme étant de classes qui indiquent le nombre d'imbrication (parce que tu as accès à l'instanciation des listes), alors oui ça devient possible, et du coup tu auras 3 classes qui définiront la dimension - ListDouble, ListListDouble et ListListListDouble ... il y a sûrement plus joli en nommage

Et ta méthode générale ressemblera à :

Code :

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

1
2
3
4
5
6
7
 
public void set(ArrayList v) { 
   if (v instance of ListDouble) {
      setListDouble((ListDouble) v) ;
   }
   ...
};

[professeur shadoko]

, il a été codé à l'origine pour manipuler les données avec beaucoup de flexibilité, grace à des méthodes massivement overloadées et des arguments optionnels.

mettons nous d'accord sur la terminologie: spécialisation (overriding) ou surcharge (overloading) la seconde étant décidée au compile-time je ne vois pas trop l'intérêt dans ton cas (?)
edit: une idée en l'air (vu que je ne connais pas le problème) tu pourrais pas inverser la proposition?

Code :

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

1
2
3
4
5
 
class UneListe<T> extends ArrayList<T> {
          public void rattacherA(UneListe<UneListe<T>> arbre){
          }
}

ou un truc dans ce genre?