> From: James Duncan Davidson [mailto:[EMAIL PROTECTED] > > > + 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
