> From: Matt Benson [mailto:[EMAIL PROTECTED] > > --- Stefan Bodewig <[EMAIL PROTECTED]> wrote: > [SNIP, re clone task:] > > Maybe I just don't understand how useful it is? > > > Usefulness would depend on the class being cloned and > what the user chose to do with it. It's almost (to my > thinking) along the lines of the Nice or Parallel > tasks in that it provides a basic and open-ended Ant > way to use a Java feature. It just happened that AFS > clones can be modified in basically the way one would > expect/hope for. A clone of an object of some other > type might not be so accommodating. The > open-endedness of the task might allow a user to > become frustrated by the misbehavior of a cloned > object; at the same time the task doesn't seem to > represent any hidden dangers of a nature worse than, > say, Delete (lesson: test your build files before > assuming they will do what you want). > In any event, this task has generated some nervousness > or distaste, and I must guess that if put to a vote it > will not pass (according to the bylaws re code > changes). The greatest part of my attachment to the > task is the research into the UE system it represents > for me, but I'm sure that knowledge will not be > wasted. On that subject, Peter expressed concern over > Clone's implementation mechanism as well (UE subclass) > but has not yet responded to my followup questions > (did you miss them, Peter?).
Leaving the debate about whether <clone> is a good idea or not aside (I tend not to like it, as I already wrote), maybe using Object.clone() is not the best way to implement this. After all, allowing to clone any Java object, not just Ant types, is probably overkill and weird. Another approach would be to use the UnknownElement of the Ant type to duplicate/augment to create a brand new instance of the same Ant type (using the normal Ant instantiation techniques for types/tasks) and configure it using the merged raw XML info in the 'parent' UE (accessed by reference) and the 'overriding' UE. This would be similar in spirit to the implementation technique in macrodef, where the raw XML info from the macro instance is weaved in with the macro definition before being instantiated. So you're not cloning a Java instance anymore, you're instantiating a new one configured exactly as the previous one modulo the changes made. I find this very similar to macrodefs, and this would allow to truly 'extend' a datatype, not just augmenting by possibly even 'overriding' attributes from the 'base' type. It's a bit like if any refid'able type is an implicit presetdef ;-) --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
