ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: antlib
Date Wed, 21 May 2003 10:31:49 GMT
> From: Conor MacNeill []
> On Wed, 21 May 2003 06:58 pm, Antoine Levy-Lambert wrote:
> >
> > I still think that the roles concept is good and I would 
> like to make a
> > separate proposal for roles. My idea would be along the 
> following lines,
> > supposing that ant is being used by specialists of geometry :
> >
> > <taskdef name="computearea" 
> class="org.apache.demo.ComputeAreaTask"/>
> > <taskdef name="computeperimeter"
> > class="org.apache.demo.ComputePerimeterTask"/> <roledef name="shape"
> > class="org.apache.demo.ShapeInterface"/>
> > <typedef name="circle" class="org.apache.demo.Circle" role="shape"/>
> > <typedef name="square" class="org.apache.demo.Square" role="shape"/>
> >
> > How this would work :
> >
> > - taskdefs are normal, just to understand how this would be used
> > - roledef : creates a hash table linking a role name with 
> an interface
> > - role attribute in typedef : do something so that 
> introspectionhelper will
> > translate addConfigured(org.apache.demo.ShapeInterface) in the
> > ComputeAreaTask and ComputePerimeterTask into :
> >
> >
> Just to be clear, this was not Jose Alberto's original Role 
> model proposal :-) 
> There, I believe, it was the task (container) that 
> implemented the interface, 
> not the element being added. I am strongly against that approach.

Well I have to say you are mistaken, in my proposal the task (container)
implemented the addConfigured(InterfaceRole) method. The interface was
for the thing being passed (the child element, after possibly some adaptor).

> With your approach, I wonder why we need all the machinery. 
> Why not just do 
> this:
> If a class supports addConfigured(ShapeInterface) AND we have 
> a type <circle> 
> for which there is no nested creator (addCircle, 
> createCircle, etc) AND there 
> is a global typedef of <circle> ANDthe typedef'd class for Circle is 
> assignment compatible with ShapInterface 
> Then 
> instantiate org.apache.demo.Circle and pass it to the 
> addConfigured method. 
> With this approach there is no need for roledef, hashtables 
> and you are not 
> restricted to interface types. It should even work for 
> <mylib:newcircle> :-)

The reason had to do with been able to deal with object (classes) that may
implement multiple interfaces. The code should not pick just
any arbitrary interface for which it happens to be an addConfigured(Interface)
in the container and just use it. If the object implements 5 interfaces
for which we have addConfigured(InterfaceN) which one should we used?
Definetly it should not be taken by chance. Part of the reason
for the infrastructure is to try to minimize this cases and allow users to
resolve when this issues arise.

If your implementation class can be used to acomplish 5 different things
then a well written <antlib> can give diferent names
when roles may appear on the same task. Still you just have
to maintain your one implementation class, but at the ANT level you
provide 5 different roles.

> As I have always maintained, this approach only gives one 
> point of flexibility 
> in a task for a given type. If I have a ShapeMapper task which has a 
> fromShape and a toShape, I can only use this technique to 
> extend one of these 
> elements. It is this reason why I prefer type specifiers.
> Nevertheless, perhaps both approachs can be supported and we 
> would benefit 
> from the syntactic niceness of not requiring type specifiers in many 
> situations. The task writer could decide. For tasks which just need 
> flexibility in one element add() or addConfigured() could be 
> used while type 
> specified could be available for tasks that need that flexibility.

I have no problem with that. Although I wish we could explore if there
are alternatives without the need for type-specifiers. But I do not
hold my breath.

Jose Alberto

View raw message