ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Date Wed, 13 Sep 2006 15:15:21 GMT
> Sorry I did not read all the svn commit emails. Which classes implement these role definitions

None, at least none that "define" a role.

Peter has extended IH and co. to lookup nested-element in tasks/types
that have add(X)-type methods, in a new mapping he called restricted
types (because they cannot use by themselve, only as nested element of
declared tasks/types).

Suppose I write FooTask in my bar AntLib. If FooTask as a
add(Condition) method, as of now, I can only use as nested elements
conditions which have been explicitly typedef'd.

Currently, there are none in Ant.

There is an antlib.xml for conditions, but I'm forced to explicitly
load it to be able to use them in my FooTask, and doing so I bring
them all into the "global" tasks/types mapping, so they can be used at
the top-level in <project> or <target>.

Peter's "restricted" types form a new mapping (I would normally say a
new namespace, but it becomes confusing because of XML namespaces...),
which is used exclusively to resolve add(X)-type methods.

This new mapping doesn't define any roles. The role that one of this
mapping will play in a task will depend on (1) the add(X) method of
that task, and (2) the types this one mapping is compatible with (in
the sense of instanceof or Class.isAssigneableFrom).

So there's no real notion of a role, IMHO. Which is why I'm not fond
of using <roledef> to declare this "restricted" types. I believe Peter
now added a 'restrict' attribute to <typedef>, which I'm also not fond
of, but it may turn out to be the less controversial choice...

No code to look at yet, since I don't think Peter posted his diffs to
BugZilla yet. --DD

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

View raw message