Le Mardi 3 D�cembre 2002 16:07, Dominique Gallot a �crit :
>
> 1- Calme, c'est pas moi qui ai pos� la question en premier !
>
Excuses-moi je ne me suis absolument pas aper�u que ma r�ponse pouvait �tre
interpr�t�e dans un sens n�gatif. Ce n'�tait absolument pas mon intention. Je
voulais juste te r�pondre normalement.
> 2-Il est vraiment absurde de dire, de Clonable
>
> * A class implements the <code>Cloneable</code> interface to
> * indicate to the {@link java.lang.Object#clone()} method that it
> * is legal for that method to make a
> * field-for-field copy of instances of that class.
>
> Et puis d'avoir un tableau d'objects qui indique qu'il est permit de
> cloner l'oject et de ne pas pouvoir le faire !
>
Effectivement.
> 3- Ce n'est tout a fait vrai.
>
> 1-Il est possible d'utilise le meme mechanisme que la serialisation pour
> cloner des objects, "c'est la reflexion/introspection", meme si
> elle n'implemente pas Serializable
> regarge java.lang.AccessibleObject.setAccessible()
> ET en implementant un security manager different de celui
> par default, qui pour info, ne permet ce call, que si il vient des core
> package.
Je connaissais pas ce AccessibleObject, j'irai voir.
> 2- Idem pour clone, on peut meme via des packages de manipulation de
> bytecode ( tt-byte) , implementer l'interface Clonable
> et puis via ce meme package marquer la methode clone comme public, ou
> encore, utilise le java.lang.AccessibleObject.setAccessible() sur
> l'object Method. Mais la cela deviens vraiment bcp pour par faire
> grand chose, quoi que, lorsque l'on sait comment les proxy sont fait,
> cela le devient moins ( java.lan.reflect.Proxy et la helper class
> sun.misc.ProxyGenerator, tt-byte n'a rien inventer ).
>
C'est vrai que l'on peut aller manipuler le bytecode. Pour les proxy, je vois
moins bien le rapport. Les proxy fonctionnent avec des interfaces, il me
semble ? Comment fais-tu ensuite ?
> Je pointais simplement le probleme que Clonable, pour moi, devrait
> - avoir la methode Clone()
Cela aurait peut �tre �t� plus habile, mais il restait � concr�tiser cette
m�thode quelque part. Sun a choisi de la concr�tiser directement dans Object,
sous une forme protected, ce n'est pas g�nial, mais ce n'est pas mauvais non
plus.
> Maintenant je sais que Sun l'a fait afin que du code externe ne puisse pas
> cloner des objects inconnu. Ce qui finalement ne sert a rien, car
> si le descendant possede une method public clone, l'introspection permet
> facilement de passe outre !
>
Si le descendant possede une m�thode public clone, c'est que le concepteur de
la classe a pens� bon de rendre cette m�thode publique. Donc, c'est bon.
> Donc J'ecrit EN GROS sur mon bureau, que impossible n'est pas java ! ( mais
> gros comment ? )
>
Encore une fois, excuses moi pour cette reflexion trop vite �crite.
--
SARL diaam informatique - 04 50 77 12 60
Ingenierie, d�veloppements de syst�mes d'information
http://www.diaam-informatique.com
