To keep things simple and make it easier to get an agreement -
let's let adapters out, and focus on the core issue.
IMO it seems what everything leads to is the need to extend
the introspection patterns with another case. Let's agree
on this pattern first.
Assuming:
<parent>
<myChild>
</parent>
If ParentClass has no addMyChild()/createMyChild() method, we'll need
to look up in some table and find a class associated with <myChild>.
( it can be the "roles" table, or just the typedef table, or some other
table that uses the context info or adapters ).
Then we'll find some interfaces associated with MyChildClass - either all
interfaces, all interfaces and base classes, or only an explicit set
declared in some other data strucutures. Each of the interface will be
a potential role.
We'll then look in ParentClass for an add method with that particular
interface as parameter.
The points of disagreement:
- should we add a separate table for <child>->class association - or just
use the typedef ?
- Should we use (<parent>, <child>) tuple to find the class? Should we use
(ParentClass, <parent>, <child>) tuple ? Or just <child> name - i.e.
context-free ?
- try all interfaces - or have some data structures to restrict to only a
subset ?
- addComponent( MyRole ) or addMyRole( MyRole ) or both ?
I.e. a fixed-name method, with overloading to support multiple roles,
or one add method per role ?
In the second case, we'll need some additional metadata to associate
the role interface with the suffix of the add method.
( MyRole -> org.apache.tools.ant.MyRoleInterface )
- should setComponent be used to indicate single-child ? ( of course, all
primitives that can be used as attributes will remain attributes )
The syntax used to create the data structures, adapters, antlib, etc
can be resolved separately - let's just add the extra introspection pattern.
Costin
