Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: <clone> or file collections
Date: Tue, 11 Jan 2005 11:45:31 -0600
Message-ID: 
 <A672996F85AA7240A9DD2A455BD0D428877D65@HOUEXCH902.landmark.lgc.com>
Thread-Topic: <clone> or file collections
Thread-Index: AcT4A5UVGmFzY2r3Q4em9GcDxYBMMAAADdqg
From: "Dominique Devienne" <DDevienne@lgc.com>
To: "Ant Developers List" <dev@ant.apache.org>

> From: Matt Benson [mailto:gudnabrsam@yahoo.com]
>=20
> --- Stefan Bodewig <bodewig@apache.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org