Generics et Comparator

Bonjour,

J'ai le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

@SuppressWarnings("unchecked") @Override public int compare(Data d1, Data d2) { Comparable<?> c1 = (d1 != null)? d1.getField(sortFieldId) : null; Comparable<?> c2 = (d2 != null)? d2.getField(sortFieldId) : null;   if (c1 == null) return -1;   if (c2 == null) return 1;   if (sortAsc) return ((Comparable)c1).compareTo((Comparable) c2); else return ((Comparable)c2).compareTo((Comparable)c1); }

---

Je dois comparer les champs (c1 et c2) de deux objets de données (d1 et d2).
J'ai écrit un truc qui fonctionne (en virant les warnings sur les 2 derniers return par @SuppressWarnings("unchecked")).
Bon, ça fonctionne car c1 et c2 sont toujours du même type et sont toujours des objets comparables (ex Comparable<String>, Comparable<Integer> ...)

Seulement, je ne trouve pas ceci très élégant !

Alors, je demande à ceux qui maitrisent les generics s'il y a une manière plus propre d'écrire cela ?

Je part du principe que getField retourne un Comparable<?>. C'est en fait là que se trouve le problème :) Il faudrait que la valeur de retour soit plus typée pour pouvoir l'utiliser. L'ennui c'est que, je suppose, suivant l'index, t'as pas la moindre idée du type de comparable.... Tu peux peut être essayer avec Comparable<? extends Object> mais je suis pas convaincu.... Tu risque de devoir te coltiner les warning. Note que, si tu regarde la source de ArrayList, tu verra que sun se coltine aussi pas mal de suppressWarning :D

Oui, getField retourne un Comparable<?>
et oui, j'ai pas la moindre idée du type de comparable, parfois c'est Comparable<String>, d'autre fois Comparable<Integer>, ...

J'ai également essayé Comparable<? extends Object> mais pas mieux ...
soit des warnings, soit des erreurs ...

J'ai également pensé à la possibilité de passer le type de comparable à la méthode getField() mais je ne sais pas trop comment m'y prendre ?

Citation:

---

si tu regarde la source de ArrayList, tu verra que sun se coltine aussi pas mal de suppressWarning

---

Je sais pas si c'est inquiétant ou rassurant :mrgreen:

C'est juste pas toujours possible de dire au compilo que "c'est correct, çà marchera" -> le suppress warning. Si on en avait pas besoin sun l'aurais pas inventé :p


Pour passer le type de comparable, tu peux faire:

Comparable<T> getField(int column, Class<T> type){..........}

Mais tu risque de déplacer ton problème dans getField() (à voir dans son code si c'est possible....)

Salut,

Perso un @SuppressWarning ne me dérange pas dans ce cas là...


:arrow: L'objectif des Generics est de vérifier le type des éléments à la compilation, afin de fournit un code typesafe. C'est à dire qu'un code Generics qui compile sans warnings ne générera pas de ClassCastException.

Ici tu utilises un type inconnu : en lisant le code de ta méthode compare() on ne peut pas déterminer le typage de tes objets Comparable, et du coup on ne peut pas garantir que les deux types soit compatible...

:arrow: Le compilateur ne peut pas s'assurer de la légitimité du code, et génère donc un warning pour le signaler. En utilisant @SuppressWarning tu indiques donc au compilateur que tu prends à ton compte la responsabilité de la cohérence du typage...


Par contre je te conseillerais d'utiliser une méthode private qui contiendra le code unsafe, et de n'utiliser le @SuppressWarning que sur ce code. Ceci afin d'éviter de cacher d'autres warnings sans le vouloir...



Sinon il pourrait être intéressant de voir le code de la méthode getField()...


a++

Merci pour vos réponses,

Citation:

---

Envoyé par adiGuba

Salut,
En utilisant @SuppressWarning tu indiques donc au compilateur que tu prends à ton compte la responsabilité de la cohérence du typage...

---

Oui, c'est ça, je prend la responsabilité ! 8-)

Citation:

---

Envoyé par adiGuba

Sinon il pourrait être intéressant de voir le code de la méthode getField()...

---

Rien de bien folichon, juste un retour d'une String (qui implemente Comparable<String>), un retour d'Integer (qui implemente Comparable<Integer>), etc ... bref, des retours de type simples pour commencer ... voir peut être des retours de certains de mes objets qui implémenteront Comparable.

Mais comme le dit tchize_, je risque donc de déplacer mon problème ...


Sinon, tant qu'on est à discuter des comparables et des generics, il y a deux points qui pourraient être améliorés dans le JDK (à moins que ce ne soit pas possible ??? mais pourquoi ?) :

Premièrement, pourquoi, alors que Integer, Long, Double et Float dérivent de Number, cette dernière n'est pas Comparable<Number> ?

Deuxièmement, pourquoi les objets de types simples + String + éventuellement Date n'implémentent pas une interface "SimpleType". Je suis d'accord que dans de nombreux cas, c'est un problème de conception (sinon ce n'est plus la peine de faire du typage static) mais il y a toujours quelque rare cas où ça m'arrangerait. A part Object, je n'ai trouvé que Serializable comme point commun mais ça reste un peu trop fourre tout à mon goût. La seule autre manière plus propre que j'ai trouvé est de faire des "Adapter" pour les types simples, mais ça fait une encapsulation de plus :(

Qu'en pensez vous ?

Citation:

---

Envoyé par benwit

Rien de bien folichon, juste un retour d'une String (qui implemente Comparable<String>), un retour d'Integer (qui implemente Comparable<Integer>), etc ... bref, des retours de type simples pour commencer ... voir peut être des retours de certains de mes objets qui implémenteront Comparable.

---

Disons que s'il y a une possibilité pour faire un code 100% Generics, cela passera par là... donc il aurait été intéressant de la voir ;)

Maintenant si tu utilises la reflection il y a de forte chance que tu doivent quand même passer par un @SupressWarning...

Citation:

---

Envoyé par benwit

Premièrement, pourquoi, alors que Integer, Long, Double et Float dérivent de Number, cette dernière n'est pas Comparable<Number> ?

---

Car les Generics n'implémentent pas un tel héritage qui peut aboutir à des états incohérents.
Par exemple si ce code compilait :

Code:

---

1 2 3 4 5 6

Integer integerObject = new Integer(0); Double doubleObject = new Double(0.0);   Comparable<Number> comparable = integerObject; // ERREUR   comparable.compareTo(doubleObject);

---

:arrow: On appellerait compareTo(Integer) avec un Double !
Bref on se retrouverait dans des cas incorrects qui génèreraient des erreurs à l'exécution, et c'est exactement ce que les Generics sotn cencé combattre ;)

Citation:

---

Envoyé par benwit

Deuxièmement, pourquoi les objets de types simples + String + éventuellement Date n'implémentent pas une interface "SimpleType". Je suis d'accord que dans de nombreux cas, c'est un problème de conception (sinon ce n'est plus la peine de faire du typage static) mais il y a toujours quelque rare cas où ça m'arrangerait. A part Object, je n'ai trouvé que Serializable comme point commun mais ça reste un peu trop fourre tout à mon goût. La seule autre manière plus propre que j'ai trouvé est de faire des "Adapter" pour les types simples, mais ça fait une encapsulation de plus :(

---

Tu veux faire quoi exactement ?


a++

Citation:

---

Envoyé par adiGuba

Disons que s'il y a une possibilité pour faire un code 100% Generics, cela passera par là... donc il aurait été intéressant de la voir ;)

---

C'est pas que je ne veux pas montrer, seulement quand je dis qu'il n'y a pas grand chose, c'est au 1° degré :

Code:

---

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

class Person implements Data { public Comparable<?> getField(String fieldId) { if (fieldId == null) return null;   if (fieldId.equals("name")) return name;   if (fieldId.equals("age")) return age; }   protected String name;   protected int age; }

---

Citation:

---

Envoyé par adiGuba

Tu veux faire quoi exactement ?

---

Avec GWT, je voulais envoyer une map d'objets à actualiser, map d'identifiant/valeur. L'identifiant est une String mais la valeur peut être aussi bien un objet GWT à moi (Composant graphique, ...) qu'un objet de type simple.
J'ai donc pensé à trois possibilité pour typer cette Map :

Solution 1 :
Map<String, Object> permet de faire ce que je veux mais GWT refuse les Object car c'est trop générique à son goût. Sur quoi, il n'a pas foncièrement tord car je connais mes objets et les types simples (String, Date, Number, Boolean). Il est juste un peu restrictif en faisant une erreur au lieu d'un warning.

Solution 2:
Map<String, Value>
Je fais une interface Value qui illustre bien la sémantique de ma conception. Cette interface est implémentée par mes objets GWT à moi.
J'ai fait un adapter génerique pour transformer les types simples en value :
ValueAdapter<TS> implements Value.
Cela fonctionne mais c'est un peu lourd d'encapsuler les types simples.

Solution 3:
Map<String, Serializable> car Serializable est le seul point commun autre qu'Object pour les types simples. Cela fonctionne avec GWT (juste des warning parce que leur compilo regarde parmis toutes les classes compatible et certaines des leurs n'ont pas de constructeur par défaut)