ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: antlib descriptor
Date Thu, 21 Feb 2002 18:05:03 GMT
Connor you are misunderstanding what roles are
designed for. They are not designed as a way to allow
polymorphism of arguments to methods.

In all your examples, the objects you are trying to
pass belong to one unique role, i.e data-type.
Your proposal, make deal with polymorphic arguments,
however it does not resolve the issue of roles like
Tasks or datatypes. If we were to use your mechanism
we will finish with build files like:

<target ...>
     <task ant:type="javac" .... />
     <task ant:type="copy" .... />

But why then not say <task ant:type="parallel"> to
start with?

You will have to make a special case for TaskContainer
and we will be back on the same crappy spot we have
been sitting for more than a year.

Now, no one is advocating defining new interfaces for
each and every method you want to allow overloading.
That would not work because you not only need to add
the interface to the Container, but you also have to
declare the objects as belonging to the role defined
by the interface. By the same token, in Peter's world,
for every type (i.e., data-type) you declare you would
have to declare a "role" for that type and add every
data-type that is a subclass will have to be
registered as belonging to the role.

This is definetly not the way to go for polymorphism.

Finally, roles are not only for adding nested
elements. They are to register functionality. For
example I would like to have a "javac" role in which
libraries can register CompilerAdapters.

<javac> will use the value of the property
'build.compiler' to search on the 'javac' role for one
with the specified name. 

So as you can see, roles have its distinctive specific

Now lets talk about POLYMORPHISM in its own right.

In my opinion, the problem we have in ANT, if that we
mix in the syntax of an element: the name of the
element to use AND the name of the method to invoke.
Polymorphism requires a way to diferentiate one from
the other.

Your approach provides that separation, so it solves
the polymorphic issue. The thing I do not like about
it is that it breaks completely any resemblance of
DTD. In other words there is no way for AntStructure
to generate a DTD. Why?, see the example:

     <fromFS ant:type="zipfileset" 
     <toFS ant:type="classfileset"
        <root classname=""/>

There is no way to define a DTD for <formFS> or <toFS>
because its structure depends on the the value of
'ant:type' and not on the value of the tag. 

A much more XML friendly way would be to let the
element describe the type and the attribute describe
the method to use:

   <zipfileset ant:as="fromFS"  dir="htdocs/manual" 
   <classfileset ant:as="toFS" dir="build/classes">
        <root classname=""/>

In other words, the element describes the type and the
"ant:as" attribute specifies the method to use.
This has the same expresive power as your solution and
there is hope for a well defined partial DTD.

This looks to me as a much better alternative to
polymorphsim, however it still does not cover the job
of roles. So we may need both concepts.

Lets the thoughts begin....

Jose Alberto

 --- Conor MacNeill <>
wrote: > Peter Donald wrote:
> > On Wed, 20 Feb 2002 19:31, Conor MacNeill wrote:
> > 
> >>Having thought about this a bit more I think,
> besides the hokiness of
> >>having to implement a separate interface for every
> extensible nested
> >>element I want to support
> >>
> > 
> > Why do you think it is "hokey"?
> > 
> > 
> If I have a method
> addFileset(Fileset f)
> that should be enough to allow it to be configured
> with a Fileset or any 
> subclass of fileset. It should work whether Fileset
> is a class or an 
> interface. I really don't think I should have to
> implement an interface 
> for each different addXXX method my task supports.
> That's "hokey" :-)
> Not only that, if I don't think ahead, the task will
> not support 
> extensibility for any elements for which I do not
> create and implement 
> an appropriate interface. Thats just bad.
> >>there are problems when a task supports two
> >>nested elements with the same underlying type.
> >>
> >>For example, consider a task which takes two
> filesets
> >><diff>
> >>   <fromFS .../>
> >>   <toFS .../>
> >></diff>
> >>
> >>It has methods like this
> >>addFromFS(Fileset from);
> >>addToFS(Fileset to);
> >>
> >>I cannot have both of these being extensible. 
> >>
> > 
> > Im not sure why you couldn't just have something
> like
> > 
> > public void add(Fileset fs)
> > {
> >   if( null == from ) from = fs;
> >   else if( null == to ) to = fs;
> >   else throw new Exception("Too many FileSets!" );
> > }
> > 
> Well that would introduce ordering semantics into
> the nested elements 
> where today the order of nested elements is
> unimportant. Further, most 
> addXXX methods can accept multiple instances and
> accumulate these. This 
> would no longer be possible.
> The problem with role based extensibility is that
> you are trying to 
> determine two independent things from one name. They
> are the method to 
> call (addfromFS or addToFS) and the actual type of
> the instance to be 
> passed to the method. With only one piece of info
> you need to 
> artificially limit the choices.
> > In either case I don't think it is simple for the
> userto have multiple 
> > extensible elements within the same element. 
> If <ejbjar> were to be implemented today it would
> not be a matching 
> task. It would take two filesets, one the set of
> deployment descriptors 
> to be processed and the other the support files to
> be included in the 
> jar.  In a particular use, I might want one to be a
> zipfileset to read 
> the descriptors from a Zip and the other to be a
> classfileset to bring 
> all the necessary support classes into the jar based
> on some root classes.
> > How would they tell when an 
> > instance of one extensible is meant to be used and
> not an instance of the 
> > other extensible type? Especailly troubliung given
> that the same name may 
> > exist in each role but represent different
> classes.
> > 
> Yes this is the problem with roles in this context.
> In mutant the user 
> provides two pieces of info - one determines the
> method - this is the 
> nested element name - and the other is the type of
> the instance to be 
> passed to the method - this is supplied by the
> ant:type attribute.
> <diff>
>     <fromFS ant:type="zipfileset"
> dir="htdocs/manual" 
> prefix="docs/user-guide"/>
>     <toFS ant:type="classfileset"
> dir="build/classes">
>        <root classname=""/>
> </diff>
> that is simple.
> > 
> >>If we have to have roles, I think they must be
> based on the class
> >>supported by the nested element rather than the
> container.
> >>
> > 
> > +1
> Well at least this would remove some of the
> hokiness.
> Conor
> --
> To unsubscribe, e-mail:  
> <>
> For additional commands, e-mail:
> <>

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message