antlib

[Antoine Levy-Lambert <le...@tiscali-dsl.de>]

I have prepared a few days ago some html pages located under http://ant.apache.org/projects/antlib/index.html
They might be interesting if you want to read more about the proposal of Jose Alberto Fernandez.
These pages do not explain yet the proposal of Peter Reilly due to the fact that I had prepared them right before Peter submitted it.

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 :


addConfiguredCircle

and

addConfiguredSquare

the role attribute would allow an expansion of the addConfigured method to suit different typedef names which are expected in the project.

Antoine

Re: antlib

[Conor MacNeill <co...@cortexebusiness.com.au>]

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