Stefan Bodewig wrote: > 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). You're right. With addConfigured() proposal - it can have only one method with a particular interface, so this is not a case. Let me think about this use case. >> - should we add a separate table for <child>->class association - or >> just use the typedef ? > > A single table. Good :-) >> - 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. In the second case, the parent class is also used when constructing the child - i.e. introspection or some other info could be used. BTW, by <parent> I mean parent namespace + parent element name ( even if we don't use ns yet ). >> Or just <child> name - i.e. context-free ? > > No, would already break down today. In this case I think the first change should be in ComponentHelper signature, which now creates the tasks/types/etc based only on NS and element name. >> - 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. Not even the name of the interface - just allow the user to use an intuitive name. But you're right - this open the case where multiple interfaces with the same parameter are used, and we'll not know what to call. >> 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. Ok. > 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> Well, the child is still created by the element name - you are solving "what method to call" problem. > The alternative approach (taken by Mutant IIRC) would look like this > > <dependset> > <srcfileset src="some.zip" type="zipfileset"/> > </depenset> > 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. Not allways, only for tasks that have overloaded/ambiguous methods. The "type" could be the local part of the add method ( addZipfileset ), which sounds intuitive. > 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. +1 > 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-) For non-overloaded case - which in the original antlib proposal doesn't seem to even be possible - I think determining the method to call is simple, and no extra info is needed. For overloaded methods - one way or another we'll need additional info from the user. I'm fine with either syntax - I would preffer the "type" attribute ( which could be an ant:type when we add namespaces ), but I'm ok with either solution. Not sure I understand your position on "how to create the child class", the overloaded method is related to "what add method to call". You seem to preffer "use parent element name and child element name". I'm ok with this - we'll just need to figure what syntax will be used to express this, and change the ComponentHelper ( or whatever else we use to create tasks ) methods to take this info as params. Costin
