> From: Costin Manolache [mailto:[EMAIL PROTECTED] > > 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. >
I think my main point of disagreement is the assumption that you can assume a unique definition for "myChild". As with the "jboss" example of my previous message there may be several definitions depending of the context of usage. What this means is that you first need to look at the parent to get the context of usages and then look for "myChild" given that context. Once you do that the rest is trivial. This means that there should be one table per role-interface. This is all introspection has to do. How we fill this tables we can treat separately, I agree. > > 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 ? > As I said, it should be (ParentClass, "childname") --> (RoleInterface, implementationInstance). If there is no unique answer we have an ambiguity. After this use method implementing RoleInterface and pass implementationInstance. > - 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 ) > I prefer a fix method, there is no need to add a name that would have to be global forever because it will be ingrane on every class implementation. > - should setComponent be used to indicate single-child ? ( of > course, all > primitives that can be used as attributes will remain attributes ) > I do not like giving special priviledges to one and not the other. If and when we change so that setFoo can be used to signal just one Foo element, then we can do the same for roles. Otherwise it is just as simple to ask users to do their own checking like they do for addFoo today. > > The syntax used to create the data structures, adapters, antlib, etc > can be resolved separately - let's just add the extra > introspection pattern. > Fine. J.A. > > Costin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
