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
