ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Roles (was: antlib)
Date Wed, 30 Apr 2003 16:53:03 GMT
Stefan Bodewig wrote:

> On Tue, 29 Apr 2003, Costin Manolache <cmanolache@yahoo.com> 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

 

 



Mime
View raw message