ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kuiper, Arnout" <Arnout.Kui...@nl.origin-it.com>
Subject RE: Ant Principles (Design pattern)
Date Fri, 21 Apr 2000 16:36:47 GMT
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> > > + Object is created inside task, so no need to find the correct
> > >   type in some intelligent way. This makes the creation a lot
> > >   faster, and might prevent classloader problems.
> 
> True, but then the programmer is responsible for providing that.

OK, but it is probably one line a-la:

Object object = new Type();

Which shouldn't be that much of a burden on the programmer.

> > > + No conflict with the addText(String) method
> > > - When the task is encapsulated, you cannot add an existing
> > >   object of the correct type. You have to create a new one
> > >   with createXxxx to add it, and fill the fields.
> 
> Right, and this is a big negative. The ability to do things of this
> nature without having to create your own class types would be nice.
>
> Yes.. Lets. :)
> 
> > I woud just rather that Ant didn't support both (except, 
> perhaps briefly as
> > a migration aid).
> 
> +1

If I take the size of the positives and negatives into account,
I end up with the addXxxx() method. This means that we cannot
have nested elements using the "text" tag. This is probably
not a big problem (as long as it is documented in the
documentation for task writers), because you can always use
a synonym. The first + on createXxxx() is just a convenience
problem for the Ant reflector, which can be solved. Speed can
be gained with caching (See a recent mail from Ludovic and my
reply to it).

So a calculated +1 on the addXxxx() for me.

When this is hammered out, I can write some detailed spec on the
design pattern/introspector if you want.

  Arnout

Mime
View raw message