ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Roles (was: antlib)
Date Tue, 29 Apr 2003 13:54:44 GMT
Hi Stefan,

Let me start by saying that the roles proposal had not in mind
solving the polimorphism issue (which I think is what is at the bottom 
of your points here). I have no problem on arriving to a solution that
covers this aspect, but I do not want it to be the stumbling block
on the whole thing. 

> From: Stefan Bodewig []
> On Mon, 28 Apr 2003, Costin Manolache <> wrote:
> > - 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.

I agree with you here, the main problem I see with adding a "MyRole"
name to the name of the method is that it will hardcode this name
in the code of everyone. Moreover this will be a global name which
will complicate any handling of 3rd party roles and implementations.
I think this would be a name administration nightmare.

In the antlib proposal the name of the role (or as I would like to call it
the alias for the role is only to help on declarations but with
respect to the code of programmers such names are irrelevant, 
the only thing they care is Java types.

> 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=""/>
> </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="" element="srcfileset"/>
> </dependset>
> The alternative approach (taken by Mutant IIRC) would look like this
> <dependset>
>   <srcfileset src="" type="zipfileset"/>
> </depenset>
> Here the approach is to look up the expected interface by the method
> name.
> 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.

As I said at the begining roles where not design for doing this.
There are several things we need to consider, first is whether
the task uses "create" or "add[Configured]", certaintly the use 
of "create" will disallow we passing a different object.
But if you look at ANT today you will see that in both cases we allow
passing a different instance via refids (actually is upto
the data-type to support this).

Now if the datatype where to allow specifying something equivalent
to a refid but in place, we could get the desired effect without
major changes. So lets assume we add to the FileSet class a new method

	addConfigured(FileSet inplaceref){ 
		// do something similar to what setRefid() does.

now we can write the above as follows:

   	<zipfileset src=""/>

which it does not look too bad, and does not need special attributes.

> 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.
> 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
> I think the learning curve for beginners to grok
> <copy ...>
>   <classfileset .../>
>   <zipfileset .../>
> </copy>

This is what you would get with the current roles as long as <copy> 
has something like:

	addConfigured(Fileset fs){...}

> 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-)

I do not like the "type" attribute, type is already use on several places
like <available> an I really think the buildfiles from the first one are more 
easy to understand and write (once you know how to use it).

It means that we would need to do a better job describing how things
work genericaly and explain better the concept of generic nested elements.
But we had always had this problem of explaining how nested things work.

Jose Alberto

View raw message