ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@mad.scientist.com>
Subject Re: [RFC] AbstractTasklet with extended functionality
Date Fri, 30 Jun 2000 08:21:55 GMT
At 10:08  30/6/00 +0200, you wrote:
>Peter, I'm not sure I've fully understood you intention.
>
>I gather that you want to reduce the Task interface to achieve two
>goals, (1) get rid of the setter methods for attributes and (2) get
>some kind of automatic validation of the attributes.

essentially. Plus it becomes closer to all other similar sub-process apis
as a benefit :P

>For (1) I'm all against it, really. I'm very much fond of the way
>attributes and nested elements are reflected into tasks. It would
>probably also break scripting support.

you want to keep it ? Easy keep it. In 90% of cases you can keep it and
inherit from AbstractTasklet. AbstractTasklet will then perform all the
reflection and setting of properties etc that is currently done in other
classes (currently it is scattered through parser). This will become even
more useful when we move to deferred instantaition of tasks. 

So in effect you can ignore it and as long as you inherit from
AbstractTasklet it will behave exactly as it does now. However in cases
where it is innapropriate then you can overide the behaviour. 

So you have choice how it should behave.

>For (2), I don't get it. How would that work? What kind of validation
>could TaskContext (I assume it should happen there) provide?

The validation is done by the AbstractTasklet and can be done any number of
ways. Mainly it is of the form parameter X is required and parameter Y is
required if parameter Z is set etc. Nothing complicated but extremely
simple syntactical validation. I have something similar that validates cmd
line arguments and is a life saver. But again if you don't want to use it
don't and the Task will behave identically to how it does now.

However if you need to it then it is there. It is just that most of my
tasks are scattered with things like

if( null == m_someProperty )
{
  throw new BuildException("Property 'someProperty' not set");
}

and combine that with the large numbers of mutators (and soon to be
accesors if you need scripting) and you get large amounts of non-dense code
that is really annoying :P


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

Mime
View raw message