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. 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. 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. 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. Stefan
