Reprise du message précédent :
mouarf, le temps que je tape mon post, y'a déjà la question et une mauvaise réponse.

ben quand il faut il faut quoi.
et la lenteur de la reflection en java, c'est une légende. en 1.3 je veux bien mais depuis la 1.4 ça roule bien, et encore mieux en 1.5 parait il

quelle mémoire

pour les conneries pas de PB.  
 
Mais je serais infoutu de réciter les formules d'Euler ou des les différentier de celles de Moivre
 
 
edit : m'enfin on s'en fout pour les maths, google est là.

j'ajouterais à la réponse de kadreg, que en java, il faut en plus que *tout* ce qu'on veut cloner soit cloneable, ce qui est de la responsabilité de l'utilisateur.

certains produits l'utilisent mais c'est vraiment la dernière roue du carosse et souvent ils imposent des contraintes (présence d'un constructeur par copie par copie) qui te force en fait à faire la grosse partie du boulot.

-- > tu l'utilises pour quoi ton protypage ? J'ai jamais vu d'exemple d'utilisation de ce truc qui me plaise.

tu parles de quoi là ?
la question pour clone() c'était pas pour moi
(l'exemple ici etant un editeur de terrain de jeu, ou il s'agit de dupliquer des cases.. du style t'as édité les propriétés d'un bout de terrain par defaut, et ensuite tu remplis une partie de ton aire de jeu avec ce terrain - mais pas avec les valeurs par défaut quoi)

ok, c'est justement à ça que je pensais : copier un objet "cofiguré" presque comme on veut et modifier un poil la copie pour que ça corresponde parfaitement à ses besoins. mais j'ai jamais vu à l'oeuvre.
 
Ce pattern s'appelle Prototype dans le GOF.

tout à fait.

question : (ou plutot validation)
 
3 types d'objets, mais stockés dans une liste. Ils sont tous unique dans leur catégorie.
 
Ils s'affichent dans un arbre.
 
Je veux pouvoir, via des Action, les manager (modifier/supprimer).
 
Pour éviter du code redondant, g pensé faire une interface que les 3 objets implémente, et qui oblige à implémenter une méthode delete et une méthode modify.
 
Ma question : la suppression par ex, c du ressort de qui ?
- la classe qui gère les listes
- la classe qui définit l'objet
- un wrapper
- l'interface ?
 
j'hésite entre 2 et 3...

la suppression est du ressort de la classe qui les aggrège, si c'est une List par exemple, ça se fera avec remove. Les objets peuvent avoir une callback qui sera appellée pour les prevenir qu'ils sont supprimés par contre (pour se désenregistrer de tout ce qu'ils observaient par exemple).
 
Mais clairement, un objet ne se sort pas de son aggrégation tout seul (de toutes façons, dans un cas sur 2 il n'a même pas de pointeur vers son objet aggrègeant), c'est le niveau d'au-dessus qui a l'initiative.
 
 
à moi les questions métaphysiques :
pourquoi JTextPane dérive de JEditorPane alors qu'il est sensé faire moins de choses ? En particulier, on est pas sensé lui changer son editorkit.
 
pourquoi les editorkits sont cloneable (en fait j'ai une petite idée de la réponse) ?

hum...le problème c que dans mon JTree g les objets en question...je pensais faire ca
 
Jtree + Bouton suppr appelle la méthode delete de l'interface Manageable sur l'objet, lequel appelle la classe d'agrégation pour se virer...
 
l'intéret de l'interface ce serait d'écrire le code qu'une fois, et de pas avoir à tester le type de l'objet
 
mais je sais pas si c propre parce que ca amène les objets à avoir connaissance de la classe qui les aggrége

jubijub >> nraynaud te dit de faire l'inverse: c'est l'objet qui encapsule tes bidules qui va deleter ton objet de la liste. et ça empeche pas, au contraire d'avoir ton interface et sa methode delete pour "prevenir" l'objet qu'il se fait enlever.
 
tu comprend vite mais faut t'expliquer longtemps hein

gt trop le nez dans ce que j'avais déjà fait...
 
g légèrement réécrit la classe qui liste les objets...tt passe par elle désormait : création, modif, suppression...en plus c plus clean : pour la création, je peux vérifier d'abord que ce qu'on essaye de créer n'est pas dupliqué avant de construire l'objet, alors que dans mon ancien système, l'objet était construit, confronté à la liste, et si doublon, garbage collecté (plus rien n'y faisant référence)...
 
faut VRAIMENT que j'apprenne la modélisation...mais je trouve ca assez chaud sans cours...parce que le larman par ex, j'ai l'impression que le gars fait exprès d'employer plein de termes compliqués pour bourrer le mou, genre on est que 10 à pouvoir comprendre ce que j'écris...
 
pourtant g tt les prérequis pour lire le bouquin, je programme avec un langage orienté objet, et j'ai une super bonne connaissance de la formalisation des processus d'entreprise (gestion powaaah)...
 
remarque g essayé le O'reilly normalement pour noob, pas mieux...le gars a une façon d'expliquer la différence entre une classe et un objet totalement incompréhensible...

Figure 1 : ce qu'il ne faut pas faire.

... parce que le mwinmwin de base ne comprend pas ce code quand il n'est pas bien réveillé ?
 
 
 
(remarque j'ai pas lu, c'est ptet normal)

parce qu'on file "this" à quelqu'un alors qu'on est encore dans le constructeur.

ha oui

et c mal même si on le met à la fin du constructeur ? (donc qd l'objet est tt bien initialisé ?)
 
C con ca...dans mon sys actuel, lorsque les objets sont construit, ils se notifient au gestionnaire de liste en se passant eux même en paramètre...
 
pourquoi c'est mal ?

parce que comme l'objet est pas fini d'initialiser, certaines opérations que le gars qui va le recevoir va vouloir faire risquent d'échouer.
 
Mais je te rassure : il n'y a pas de vraie méthode pour contourner ça. Le mieux qu'on puisse faire c'est documenter l'objet comme ayant explicitement 2 états successifs avec des opérations interdites dans le premier.

ok...

je veux pas polluer, mais je recherche le topic de référence sur le classloader, et je le trouve pas

 
je me mange un classCastException ce qui m'etonne pas vraiment au passage
 
c'est bien ca que tu m'as suggéré ?
 

oui.
 
Pas de chance hein ?

ca existe ca ?

il parle peut etre de ton topic sur le classpath
(le méchant confondage )

 
y'avait aucun sarcasme dans mon post
 

c'était pas un sarcasme, juste un constat.
 
Là j'ai la flemme d'ouvrir mon eclipse, peut-être demain.

je pensais, oui
j'en ai vague souvenir

vous pensez qu'il est safe le cast ? j'ai oublié un truc ?

une paranthèse?

Salut,
 
J'ai un problème spécial et j'hésite à ouvrir un topic pour un truc qui ne servira qu'à moi vu que c'est très très spécifique.
 
En fait, j'essaye d'utiliser un wrapper qui permet de créer des plug ins VST (c'est du son pour ceux qui ne conaissent pas) en java, alors qu'à l'origine le sdk est en C++.
 
Ça a l'air vraiment bien foutu mais là, je lutte, j'arrive pas à lancer ne serait-ce que l'exemple par défaut, déjà tout compilé.
 
L'auteur dit qu'il faut changer le classpath dans un .ini, ce que j'ai fait et ayant bien vérifié je crois pas que c'est ça qui merde.

Il dit aussi de rajouter le client jvm.dll sur le path global, ce que j'ai aussi fait.
 
Mais au moment de lancer le plug in dans mon soft de son, paf, une msgbox bidon, et ça plante. Je regarde le .log dans le dossier du plugin et j'ai ça :
 

Donc, mon dossier c'est G:\PlugsSon\_jVST\JayDLay_bin\ pas de problème.
 
Ce qui m'embête, c'est déjà que j'arrive pas à savoir qui écrit ce .log : en parcourant toutes les classes du programme, ainsi que l'unique dll avec un éditeur de ressources, j'ai trouvé aucune String qui comportait ne serai-ce qu'un seul de ces mots; j'imagine donc que ça vient d'ailleurs.  
Perso, j'ai jamais utilisé JNI, j'y connais absolument rien.
 
Je sais pas si vous pourrez m'aider, enfin je poste quand même on sait jamais, et merci d'avance.

url du truc stp, ça m'interesse

non, c'est pas moi, c'est joce.

 
super

bah clique sur "editer", tu verras.

 
 
ok  

meeeeeeeerde mais faut l'enfermer ce mec

lol la grosse démo

http://jvstwrapper.sourceforge.net/
 
moi j'essaye d'utiliser ça avec fruityloops. Si t'arrives à faire tourner un plugin, mets moi au courant parce que vu la tronche des sources, ça peut vraiment être fendard.