On Mon, 28 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > If ParentClass has no addMyChild()/createMyChild() method, we'll > need to look up in some table and find a class associated with > <myChild>.
OK, well, maybe, see below for an alterbative view. > We'll then look in ParentClass for an add method with that > particular interface as parameter. The use-case is too simple as the ParentClass could have more than one method with that interface (or even different interfaces implemented by the class mapping to myChild). > - should we add a separate table for <child>->class association - or > just use the typedef ? A single table. > - Should we use (<parent>, <child>) tuple to find the class? Should > we use (ParentClass, <parent>, <child>) tuple ? I'm not sure what the difference is, here. > Or just <child> name - i.e. context-free ? No, would already break down today. > - addComponent( MyRole ) or addMyRole( MyRole ) or both ? I assume you are taking MyRole as the name of the interface here, as I'm not convinced that we need formal roles at all. > I.e. a fixed-name method, with overloading to support multiple > roles, or one add method per role ? Neither is enough IMHO. > - should setComponent be used to indicate single-child ? No. Let's keep set* for Attributes. > ( of course, all primitives that can be used as attributes will > remain attributes ) Path can already be used as Attribute and as nested element. Let's take DependSet as an example. It has two kinds of nested FileSets, srcfileset and destfileset. For the sake of discussion lets assume that placing ClassFileSet or ZipFileSet for either "kind" of FileSet was useful - I think it is at least for ZipFileSet. <dependset ...> <zipfileset src="some.zip"/> </dependset> with the approach you describe, If we follow the "name determines implementation" route you've described here, both addSrcfileset(FileSet) and addDestfileset(FileSet) would be candidates for methods to call. We need a way to resolve this - probably via an extra attribute that explicitly says "I'm a srcfileset". Something like <dependset ...> <zipfileset src="some.zip" element="srcfileset"/> </dependset> The alternative approach (taken by Mutant IIRC) would look like this <dependset> <srcfileset src="some.zip" type="zipfileset"/> </depenset> Here the approach is to look up the expected interface by the method name. I feel this second approach is easier in the (rare?) cases where things are ambiguous, but it also forces people to always explicitly state the type. I'm not sure that the later is a drawback, though. With this approach the parent completely determines which element names are supported as nested elements and at the same time clearly states which interface is expected from the child element. This makes documenting stuff a lot easier. Imagine the nested elements of copy. <copy> accepts nested <fileset>s or any element whose name maps to a class that extends org.apache.tools.ant.types.FileSet? I think the learning curve for beginners to grok <copy ...> <classfileset .../> <zipfileset .../> </copy> is steeper than the alternative <copy ...> <fileset type="classfileset" .../> <fileset type="zipfileset" .../> </copy> I'm not really sure myself, I've argued the first approach myself when we discussed it the last time around (because the non-ambiguos case requires less typing 8-) Stefan
