On Tue, 29 Apr 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> 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).
It simply occured to me that <antlib> may not need any notion of roles
at all but that all issues you are trying to solve could be addressed
with polymorphism instead. So yes, I am the one who joined them.
> 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 do we really need this help on declarations? Do we really need to
say Class X implements Condition by accident, don't you dare to use it
as such?
Your <if> example doesn't hold as <if> extends ConditionBase but this
in turn does not implement Condition, which would be the interface for
the role in question.
And even if there are such cases, wouldn't documenting the fact and
throwing an excpetion if the class gets abused be easier?
> but with respect to the code of programmers such names are
> irrelevant, the only thing they care is Java types.
Exactly.
> 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.
Yes.
> 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:
>
> <dependset>
> <srcfileset>
> <zipfileset src="some.zip"/>
> </srcfileset>
> </depenset>
>
> which it does not look too bad, and does not need special
> attributes.
And every subclass of FileSet would probably have to override that
method. In addition we'd have to add it to existing interfaces,
breaking custom Mappers or Selectors for example.
> I do not like the "type" attribute, type is already use on several
> places like <available>
names ...
This is where I'd really see a magical namespace for attributes that
get parsed by Ant's core.
> 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.
Users will probably care less how things work and more what they are
allowed to write into their build file and which elements they can use
where.
I'd expect task writers to be able to understand each of the
alternatives discussed so far.
Stefan
