> From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > 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
