[Générics] Surcharge methode invalide

Bonjour,

Je suis en train d'utiliser les JTables dans le cadre d'un de mes projets, et je suis donc amené à utiliser les TableModels.
J'ai voulu créer mon propre TableModel en surchargeant AbstractTableModel pour qu'il n'accepte des objects que d'un type donné.

Code:

---

1 2	public class monTableModel<T extends Object> extends AbstractTableModel

---

Tout se passe bien jusqu'au moment de la méthode : setValueAt.
Je pensais que écrire ceci suffirait :

Code:

---

1 2	public void setValueAt(T value, int row, int col);

---

Mais là, il me sort :

Code:

---

1 2	Name clash: The method setValueAt(T, int, int) of type monTableModel<T> has the same erasure as setValueAt(Object, int, int) of type AbstractTableModel but does not override it

---

Si je change le prototype de ma méthode, en remplaçant "T" par Object, ça fonctionne, mais bien sûr je perd un peu le coté "spécialisation" de mon TableModel.

Comment puis-je faire pour résoudre ce problème ? C'est à dire pouvoir "spécialisé" ma méthode setValueAt.

Merci.

C'est normal dans la classe parente (AbstractTableModel / ou interface TableModel), la méthode est

Code:

---

setValueAt(Object,int,int)

---

Tu n'as pas le droit de changer les types des paramètres lors d'une surcharge.

Le problème ici c'est que TableModel n'est pas générique, il aurait fallu qu'il soit générique à la base pour que tu puisses faire ce que tu veux faire... étendre AbstractTableModel<T>...

Au passage ton "extends Object" ne sert à rien :)

Salut,


Ce n'est pas possible car le type T pourrait être différent de Object et donc potentiellement incompatible avec la définition de la méthode setValueAt() (même si dans ce cas précis cela pourrait fonctionner).

Le plus simple serait de te créer une nouvelle méthode en remplacement de setValueAt(), par exemple :

Code:

---

1 2 3

public void setTypedValueAt(T aValue, int rowIndex, int columnIndex) { // ton code ici }

---

Et dans setValueAt(), tu te contentes d'appeler cette nouvelle méthode :

Code:

---

1 2 3 4 5 6 7

/**          * @throws ClassCastException          */ @SuppressWarnings("unchecked") // cast (T) public final void setValueAt(Object aValue, int rowIndex, int columnIndex) { this.setTypedValueAt((T)aValue, rowIndex, columnIndex); }

---

:arrow: Tu peux mettre la méthode en final pour qu'elle ne soit plus redéfinie directement...



Pour la méthode getValueAt() tu ne devrais pas avoir de problème car la covariance des types de retour te permet de modifier le type de retour dans certains cas : (tu as de la chance car le tutoriel est publié aujourd'hui même : La covariance des types retournés par les méthodes en Java 5).

a++

Merci bien de vos explications claire et net. Ca rejoint l'idée que j'avais.

Citation:

---

Au passage ton "extends Object" ne sert à rien

---

C'est ce que je pensais, mais par desespoir, je m'étais dit "on sait jamais, sur un malentendu..." ^^'

J'avais opté pour ta solution adiGuba, mais ça laisse une petite "faille" si on passe un objet différent de T dans la méthode "setValueAt", c'était ça qui me dérangeais.

Merci quand même d'avoir pris le temps et répondre et d'argumenter vos réponses.

Citation:

---

Envoyé par MrDuChnok

J'avais opté pour ta solution adiGuba, mais ça laisse une petite "faille" si on passe un objet différent de T dans la méthode "setValueAt", c'était ça qui me dérangeais.

---

Dans ce cas, tu peux vérifier le type de l'objet dans un test, et agir en fonction:

Code:

---

if(tonObjet instanceof T) { /* ok */ } else { /* pas ok */ }

---

Citation:

---

Envoyé par CyberChouan

Code:

---

if(tonObjet instanceof T) { /* ok */ } else { /* pas ok */ }

---

---

Non, tu n'as pas le droit au "instanceof T"...
instanceof n'intervient qu'à l'exécution, le T n'est dispo qu'à la compilation...

Citation:

---

Envoyé par ®om

Non, tu n'as pas le droit au "instanceof T"...
instanceof n'intervient qu'à l'exécution, le T n'est dispo qu'à la compilation...

---

Argh! Zut! Merci pour cette précision, je ne savais pas (C'est ça de travailler tous les jours sur du java 1.4. J'essaye de me tenir au courant des nouveautés mais je ne pratique pas assez le 5.0+ pour bien connaître :? )

Citation:

---

Envoyé par CyberChouan

Argh! Zut! Merci pour cette précision, je ne savais pas (C'est ça de travailler tous les jours sur du java 1.4. J'essaye de me tenir au courant des nouveautés mais je ne pratique pas assez le 5.0+ pour bien connaître :? )

---

T'inquiète pas, c'est tentant d'écrire "instanceof T". Ceux qui utilisent les generics l'ont forcément déjà écrit une fois dans leur vie... tout comme T[] tab = new T[5]... (en tout cas moi je l'ai déjà fait...)

Citation:

---

Envoyé par ®om

T'inquiète pas, c'est tentant d'écrire "instanceof T". Ceux qui utilisent les generics l'ont forcément déjà écrit une fois dans leur vie... tout comme T[] tab = new T[5]... (en tout cas moi je l'ai déjà fait...)

---

C'est pas totalement impossible, mais il faut passer par de la réflection...

Pour la création de tableau on peut utiliser ce simple code :

Code:

---

1 2 3 4

@SuppressWarnings("unchecked") public static <E> E[] newArray(Class<E> componentType, int length) { return (E[]) Array.newInstance(componentType, length); }

---

Par contre il faut bien garder en tête que l'utilisation d'un tableau n'est pas type-safe (contrairement aux générique).



Quand à instanceof il faut être remplacer par la méthode isInstance() de Class.
Le principal problème vient du fait qu'il faut se trimballer le type générique de l'instance :

Code:

---

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

class MyClass<T> {   private final Class<? extends T> tType;   public MyClass(Class<? extends T> tType, int size) { this.tType = tType; }   public void method(Object obj) { if (tType.isInstance(obj)) { // code ici } }   }

---

Pour plus d'info sur les particularité des Generics de Java 5.0 : Les Generics ne sont pas des Templates comme les autres !


A noter qu'il existe un débat pour des Generics "reified", c'est à dire des Generics qui contiendrait le type de l'instance au runtime, ce qui permettrait d'utiliser directement tout cela... mais cela impliquerait également des incompatibilités plus ou moins importantes selon l'implémentation choisit (raison pour laquelle cela n'a pas été fait avant)

a++

Citation:

---

Envoyé par adiGuba

A noter qu'il existe un débat pour des Generics "reified", c'est à dire des Generics qui contiendrait le type de l'instance au runtime, ce qui permettrait d'utiliser directement tout cela... mais cela impliquerait également des incompatibilités plus ou moins importantes selon l'implémentation choisit (raison pour laquelle cela n'a pas été fait avant)

---

Du coup le fait d'avoir sorti une version "intermédiaire", ça va provoquer de plus grandes incompatibilités encore pour la sortie d'une future version où l'information serait présente au runtime...
(en fait pas forcément, mais bon)
fin de troll

Citation:

---

Envoyé par ®om

Du coup le fait d'avoir sorti une version "intermédiaire", ça va provoquer de plus grandes incompatibilités encore pour la sortie d'une version où l'information serait présente au runtime...
(en fait pas forcément, mais bon)
fin de troll

---

Non : la version actuelle des Generics assure une compatibilité totale :

• Une List<String> peut être utilisée dans une API pré-Java 5 qui attend une List non-générics
• Une List non-générics peut être caster en List<String>

:arrow: Ceci est tout a fait possible (mais génère quelques warnings pour signaler les problème potentiel).

Avec des Generics "reified" cela ne sera peut-être plus possible. A titre d'exemple l'introduction des Templates dans C# a obliger Microsoft à proposer une nouvelle API de Collections incompatible avec la précédente...

a++