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
