ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <adammurdoch...@yahoo.com>
Subject RE: TaskAdapter and execute()
Date Sat, 02 Mar 2002 07:39:26 GMT


> -----Original Message-----
> From: Peter Donald [mailto:peter@apache.org]
> 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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message