> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 2 March 2002 4:42 PM
> To: Ant Developers List
> Subject: Re: TaskAdapter and execute()
>
>
> On Sat, 2 Mar 2002 15:27, Adam Murdoch wrote:
> > What were the issues exactly?
>
> Lack of control for task writer. ie Theres no way for a taskwriter to
> explicitly state than they only want to expose feature X as an
> element - not
> an attribute.
We need meta-info. Not necessarily for this issue, but it would certainly
solve the problem.
> Also the format of XML representation starts to be
> significantly effected by presence of converters or not etc.
>
Yes it does. But that complexity doesn't go away when you change what addX()
and setX() mean. You've still got to deal with poymorphism, Configurable
(everyone's favourite), shared data types, recursive data types, nested element
conversion, and whatever else ends up in the configurer.
I don't think we should be changing our configuration model just because it
makes documentation generations a little tricky.
> > I'd hate to see documentation generation be
> > the sole reason we switch back. I think the behaviour we have
> right now is
> > already proving itself to be really powerful. Sure, it makes generating
> > docs harder, but it also makes writing tasks easier. Given that there's
> > going to be one documentation generator, and thousands of tasks, well, I
> > think we want to stick with what we currently have.
>
> After looking at it again I don't think it makes tasks easier to
> write. It
> removes control from Task writers and the benefit is minimal.
> Personally I
> would not mind something like
>
> void setClassPath( Path p )
> {
> addClassPath( p );
> }
>
The benefit isn't minimal. You're getting:
* One less method to write.
* Multiplicity checking.
* A clearer semantic on your object interfaces. With the Ant 1 behaviour, the
meaning of setX() is misleading when property X is multi-valued - it doesn't
*set* the property, it *adds* a value to the property.
Not huge things, granted. But handy things. And I suspect this list of
niceties that the container provides is going to grow. If we blur the meaning
of setX() and addX(), we get in the way of the container providing these things.
I think meta-info is the answer here. We've gotten to the point where we have
to guess the task writer's intention. Let's give 'em a way to make it
explicit. So, how about we leave things how they are for now, and get a basic
meta-info framework happening, then sort the mapping out. We could even go as
far as letting the task writer specify which style of method mapping to use.
As far as the docs go, we should simply list out the properties in the doco for
the time being.
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
