ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: antlib
Date Wed, 21 May 2003 10:13:33 GMT
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.

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> :-)

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.

Conor


Mime
View raw message