Stefan Bodewig wrote: > On Tue, 29 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: >> Stefan Bodewig wrote: > >>>> - 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 ). > > OK. I think we'll need ParentClass to apply proper interface > resolution. I'm somewhere on the fence, to be honest.
Same here :-) > I don't see a need for separate namespaces depending on the > interfaces, so only using the child's element name (and namespace) > could be enough. I'm not sure whether I'm overlooking a problem. Not sure I understand. Namespaces are not required to solve the polymorphism problem. My concern was the API used by ComponentHelper - I would rather add the "parent" parameter, even if it's not used now, if we expect we'll find some use cases that will require it ( say in 1.7+ ). > In a previous mail I said <child> alone would already break down > today. What I had in mind are things like the <fail> element nested > into <sound> clashing with the <fail> task - all those things that > make a DTD impossible to write for Ant. Adding namespaces could reduce this problem. The fail inside sound could use a different namespace than the core <fail> element. Without namespaces - the context ( i.e. parent ) seems to be required. In any case - making it available to the helpers that creates the components can't hurt :-) > But these existing name clashes only exist for the non-overloaded > cases that we are still going to support. I.e. they exist because > SoundTask defines addFail(SomeObject) which is fine as it is not > ambiguos at all. > >> 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. > > An alternative to a magic namespace would be magic attribute names. > We can use attributes that contain dashes > > <dependset> > <zipfileset use-as="srcfileset"> > </dependset> > > use-as quite clearly states the user's intent and it is impossible to > have an existing attribute for tasks or nested elements. Sounds good ( not "use-as", but magic attribute ). Maybe "ant:type" would be better ? The attribute should be optional - i.e. required only for overloaded elements, i.e. 2 methods with the same addXXX signature, and it should be matched against the method name. use-as="srcfileset" -> addSrcfileset() I'm +1 on this solution for the overloading problem, can't think of anything better. Costin
