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 11:54:44 GMT
On Wed, 21 May 2003 08:31 pm, Jose Alberto Fernandez wrote:
>
> 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).
>

Well I am glad to hear I am wrong. Until 7 days ago, the code in your proposal 
was this (Project.java)

    public Object createInRole(Object container, String type) {
        Class clz = container.getClass();
        String roles[] = symbols.findRoles(clz);
        Object theOne = null;
        Method add = null;

It certainly implies the roles are associated with the Container class, not 
the nested "type" name. findRoles is checking if 
Role.isImplementedBy(container class). 

Right now that method has been removed from Project.java and nothing I see 
calls findRoles. Actually I don't really understand how the proposal 
currently hangs together. 

>
> 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.
>

Won't this be relatively rare (i.e. a class implementing multiple interfaces 
being passed to a task accepting more than one of those interfaces)? If the 
nested element is implementing multiple interfaces won't it also support 
multiple roles? Or do I need to typedef the same class into two different 
typenames, one for each role. So, if my circle also implements a 
org.apache.demo.BlockInterface interface, will it support the "block" role. 
Is it (extending Antoine's example)

<roledef name="block" class="org.apache.demo.BlockInterface"/>
<typedef name="circle" class="org.apache.demo.Circle" role="shape, block"/>

or

<roledef name="block" class="org.apache.demo.BlockInterface"/>
<typedef name="circle" class="org.apache.demo.Circle" role="shape"/>
<typedef name="circleblock" class="org.apache.demo.Circle" role="block"/>

The first option would mean roles are no better at selecting a method than a 
search based on the implemented interfaces. The second would be OK, but I 
think we are getting pretty messy. An instance supporting multiple interfaces 
can't be passed to different tasks using different interfaces. A circleblock 
instance could not be passed to a task taking a ShapeInterface, because it is 
not in that Role. A class supporting multiple interfaces is probably intended 
to be used as both types of objects at different times. 

How does the multiple role situation "allow users to resolve when this issues 
arise"? What am I missing?

Overall, I still see it as a lot of complexity for the exceptional case.

Conor


Mime
View raw message