> 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
|