generics : besoin d'aspirine :D [Résolu] - Java - Programmation
Marsh Posté le 17-01-2005 à 16:45:14
bobuse : tout est en vrac, tu es sûr que c'est le code exact que tu as compilé ?
Puis avec des noms un peu plus réaliste ça serait plus facile à démerder.
Marsh Posté le 17-01-2005 à 16:56:41
nraynaud a écrit : bobuse : tout est en vrac, tu es sûr que c'est le code exact que tu as compilé ? |
oui oui, c'est exactement pareil, j'ai la même erreur !
nraynaud a écrit : |
ouaip, je vais arranger ça ...
Marsh Posté le 17-01-2005 à 17:17:28
Bon alors voilà, je repose mon pb.
J'ai une classe Position dont le contenu importe peu :
Code :
|
Et le reste de mon code qui donne l'erreur :
Code :
|
Pour la petite histoire, ce code lui compile sans erreur. Mais déclenche un warning que je me suis dit "ça serait bien de pas avoir de warning".
Code :
|
Donc je peux laisser ce dernier code qui ne déclenche qu'un warning, mais :
1 - sans warnings, c'est mieux
2 - je comprends pas pourquoi l'autre code compile pas et j'aimerai bien savoir pourquoi !
Marsh Posté le 17-01-2005 à 17:20:45
bobuse > pas trop le temps de faire un paté, mais je psenque que c'est
Code :
|
que tu cherches à faire.
relance-moi ce soir si tu veux une explication (et que je fais pas un boulot-métro-dodo)
Marsh Posté le 17-01-2005 à 17:27:31
nraynaud a écrit : bobuse > pas trop le temps de faire un paté, mais je psenque que c'est
|
Ha ouais mince, ça marche.
Heu oui, c'est vrai que mon "C extends TestC<B>" sert à rien ...
dur dur le lundi
n'empêche que je comprends pas quand même le message d'erreur, pas plus que pourquoi mon code n'était pas bon, mais bizarre je l'admets !
merci
Marsh Posté le 17-01-2005 à 18:03:17
en fait ça doit aussi marcher en mettant super à la place de "extends" dans le template de la méthode :
Code :
|
Marsh Posté le 17-01-2005 à 18:05:11
Heu ouais, mais ça me conviens pas du tout
Moi je veux pouvoir passer des sous-types
EDIT : et encore une fois, il sert à rien ton générique : tu l'utilises pas !
EDIT2 : oups, lu trop vite -> mal lu
Marsh Posté le 17-01-2005 à 18:19:56
héhéhé, réponse de débutant ...
réfléchis bien, tu verras que tu pourras encore passer les sous-types.
Marsh Posté le 17-01-2005 à 18:26:07
des sous-types de TestE, ok, mais des sous-types de TestE qui sont paramétrés par un sous-type de TestC<B>, j'ai du mal à le croire ...
Marsh Posté le 17-01-2005 à 21:13:21
en fait si tu mets super comme je te le propose dernièrement, tu vas pouvoir passer en paramètre de plop() des perceptionInterface qui sont beaucoup plus ouverts que les tiens. C'est assez fin.
prenons comme exemple les Collections.
imaginons que tu bosses sur des arborescences de fichiers.
tu as une classe abstraite DirectoryEntry avec comme sous-classe File et Directory.
tu as dans Directory, par exemple, une méthode qui va collecter les fichiers texte récursivement. Comme t'es pas con, tu fais du récursif.
tu fais donc une méthode dans Directory :
Code :
|
Bon, là c'est fessée direct, la récursivité n'est pas terminale (encore que sur un arbre on s'en fout), mais surtout, tu va allouer et merger des centaines de collections intermédiaires.
Comme la joe-la-pelle-à-clous rôde, et que y'en a marre du java qui rame à cause du développeur, tu fais un petit effort.
Code :
|
bon, ça c'est cool, c'est un bon pattern que tout le monde devrait connaître et exposer : la version pas prise de tête et la version où on pousse dedans (pareil pour toString() et writeOn(Writer w) que ces crétins de sun n'ont pas fait tout seuls). en général, on en écrit un à partir de l'autre.
voyant ceci, joe la termite ce dit : "c'est pas con, je collectionne tout un tas de bordel dont tous les fichiers textes de certains répertoires et certains autres répertoires ailleur dans l'arborescence, je vais utiliser addTxtFilesTo()".
Code :
|
joe-la-termite, il vient de te niquer ta belle fonction réutilisable ! bah oui, Collection<File> c'est pas Collection<DirectoryEntry> et tu arrête de pleurer comme ça.
c'est là qu'arrive l'acharné de la spec java 5.0 et qui dit : "trop facile pour moi".
et la soluce arrive toute seule :
Code :
|
et voiloù, il autorise à passer en argument n'importe quelle collection capable de contenir des File.
Marsh Posté le 18-01-2005 à 09:18:16
ouaip ok d'accord pas mal
pour le coup du extends, la nuit m'a porté conseil, et je comprends que ça marche ...
Marsh Posté le 18-01-2005 à 09:21:58
Mais dans mon cas, je vois pas l'utilité de la chose
Moi ça me suffit comme ça :
Code :
|
Marsh Posté le 18-01-2005 à 12:02:03
pour pouvoir passer en argument des PerceptionInterface2 admettant en paramètre des superclasses de Environment1
Marsh Posté le 18-01-2005 à 12:04:15
nraynaud a écrit : pour pouvoir passer en argument des PerceptionInterface2 admettant en paramètre des superclasses de Environment1 |
Ha d'accord ! mais conceptuellement c'est pas possible
Car le Environment1 de l'exemple est une top-classe chez moi
Marsh Posté le 18-01-2005 à 13:26:20
ReplyMarsh Posté le 18-01-2005 à 13:39:28
non, justement, là c'est pour *utiliser* des apis génériques, ton bout de code à toi, il ne l'est pas du tout.
Marsh Posté le 18-01-2005 à 13:58:01
Ben le fait que mes poissons soient paramétrés par un type de position, je voie pas quelle API j'utilise
Bon et sinon, mon autre topic ? des idées ?
Marsh Posté le 18-01-2005 à 15:57:28
Jubijub a écrit : g compris l'interet de ce truc pour les collections par ex...mais après je dois avouer que ca sort de ma compétence |
héhé
c'est pour empecher la banalisation de l'info
Marsh Posté le 18-01-2005 à 17:12:00
question tuto, celui de sun est pas mal, mais dur à digérer je trouve
J'ai beau le relire, et comprendre ce qu'il veut dire, j'oublie souvent
Il y a celui de dev.com aussi :
http://lroux.developpez.com/articl [...] #Lgenerics
Marsh Posté le 18-01-2005 à 17:26:53
bobuse > nan je projette de faire un tuto sur l'archi plutôt que sur les détails.
Marsh Posté le 19-01-2005 à 12:29:43
J'ai regardé de près et...
bobuse >
Dans :
Code :
|
tu declares le type C comme "C extends TestC<B>". La fonction
Code :
|
dans TestE veut un C du type "C extends TestC<B>" or toi lors de l'appel :
Code :
|
tu l'appelles avec un "TestC<B>" ce qui n'est pas pareil.
La preuve par l'exemple : (en modifiant ta classe TestE)
Code :
|
Les types en generiques
sont exacts.
nraynaud >
chez moi en mettant super a la place de extends j'ai 3 msg d'erreur :
Code :
|
Marsh Posté le 19-01-2005 à 14:30:14
ReplyMarsh Posté le 20-01-2005 à 09:23:31
nraynaud a écrit : j'ai changé la syntaxe du super, ça doit être mieux. |
heink ?
je vois pas ...
Marsh Posté le 17-01-2005 à 16:31:42
Bon voilà, en tripatouillant les generics, j'arrive à une erreur de compil que je ne comprends pas. J'ai simplifier le problème pour essayer de mieux le comprendre. Mais je comprends toujours pas. Si quelqu'un de motivé veux s'amuser avec ça et me donner un indice :
EDIT : j'ai réécris le code de manière plus explicite deux messages plus bas ...
L'erreur balancée par eclipse :
The method plop(B, C) in the type TestGenerics.TestE<T,C,B> is not applicable for the arguments (B, TestGenerics.TestC<B> ).
C'est ptet tout con, mais là j'y vois plus grand chose !
Message édité par bobuse le 19-01-2005 à 21:18:26
---------------
get amaroK plugin