All this discussion about roles brings me back to the
proposal/implementation
of Roles that I made a long time ago and that was rejected.
I can hardly remember it by now (or I may be reinventing it anew ;-) ),
but the key of the matter was the following (notice this was before
namespaces):
a) Roles are interfaces.
b) We have add(Interface) methods for the roles.
c) Introspection works as follows when looking at an XML element:
1) Look at ALL the classes using that name (e.g., all the classes
mapped to <and>)
2) Restrict this set to those classes implementing an interface for
which
there is an add(Interface) method.
3) If there is more than one class in the resulting set, this is a
disambiguation error.
d) If this unique class implements more than one Interface with an add()
in the context,
there is a disambiguation error. Since we do not know what method to
call.
e) Call the only method with the only class that matches.
This was before namespaces, so this may apply to the current core or
allow libraries to
use the same name for multiple things.
Now, in this situation, what would introspection need to be able to
solve ambiguities?
Example: Lets have the following definitions:
foo= ant.pack.Foo {
add(ant.Condition);
add(ant.Selector);
}
and=ant.pack.condition.And implements ant.Condition;
and=ant.pack.selector.And implements ant.Selector;
<foo>
<and .../>
</foo>
This will give an error as it will not know which <and> to use (two
classes),
Somehow you need to say which class to use.
On the other hand, we could have:
or=ant.pack.ambiguous.Or implements ant.Condition, ant.Selector;
<foo>
<or .../>
</foo>
This will give an error as it will not know which "add()" to call (two
methods, one class),
Somehow we need to say which role to use.
Using NS just means that you associate different names to different
elements. But that is
not the issue we have in core, they have the same element name. And if
core can do that,
I do not see why third party cannot do the same.
This looks to me as the need to have meta attributes that can be used to
disambiguate:
ant:role="ant.Condition" or ant.class="ant.pack.selector.And"
which are used by Introspection in case of ambiguity.
Jose Alberto
> -----Original Message-----
> From: Matt Benson [mailto:[EMAIL PROTECTED]
> Sent: 15 April 2005 22:22
> To: Ant Developers List
> Subject: RE: ResourceCollections
>
>
> --- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > Martijn, Matt, the example above would be necessary
> > if and only
> > if <resourcecollection> only had a
> > add(ResourceSelector). In
> > practice, we'll likely have specialized
> > addAnd(ResourceSelector) and co
> > so that if can be written just:
>
> oh, that's partly what I was trying to avoid. Part of
> the beauty, to me, of some of the latest introspection
> code is the ability to use add() methods. It makes me
> unhappy to have to specify element names in my
> configuration methods where there is no ambiguity.
> For example, if you have to add multiple elements of
> the same type to be used for different purposes, then
> okay, how else would you know which was which? But in
> the case of the <restrict> ResourceCollection (which
> is the context for ResourceSelectors), why should I
> have to support addAnd(), addOr(), addNot(),
> addNone(), addMajority, etc., etc., when I could code
> add(ResourceSelector) and be done with it? That takes
> us back to either forcing the explicit declaration at
> all times or trying to code something that uses
> context to decide which "and" the user means at
> runtime... fine, but also complicated and, as Peter
> pointed out, bound to encounter ambiguity errors.
>
> [trying to snip as much as possible lest these become unmanageable]
>
> -Matt
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
