ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: cvs commit: jakarta-ant-myrmidon/framework/src/java/org/apache/myrmidon/framework/filters
Date Wed, 24 Apr 2002 05:31:59 GMT
On Wed, 24 Apr 2002 13:46, Peter Donald wrote:
> On Wed, 24 Apr 2002 12:40, Adam Murdoch wrote:
> > On Wed, 24 Apr 2002 12:21, wrote:
> > >   Log:
> > >   Combine role short and long names, so that a role has one name only:
> Dont throw away the long names. If you are going to remove one version of
> the names then remove the short version as that s only a logical name while
> the Role name coresponds to interface classname.

Yes, but using the classname becomes meaningless when the roles are spread 
across different classloaders, and becomes unworkable when multiple versions 
of the same role class need to be referred to (e.g. when multiple versions of 
an antlib are being used, or when multiple versions of the container api are 
being used).  The other case where the classname convention isn't 
particularly useful, is where the role is untyped, and has no associated 
interface (as data-type might end up, say).

Given these things, the long name is also just a logical name for the role.  
At the end of the day, the long and short names both have the same semantics 
- each is simply a unique logical name for the role.  The longer ones mean 
less chance of name collision, the shorter ones are easier for humans to use.  
And neither of them really solve the problem.  Hence going with the 
shortname, and ..

> The only purpose of the shortname is to make writing deployment descriptors
> easier. It should not be used in our code at IMHO.

There's also anywhere that a human needs to refer to a role.  Right now, 
there's <import type="roleshorthand" ... > and <typedef type="roleshorthand" 
... >, but there's no reason we won't be adding more places.

> > The plan here is to eventually redo role management, to deal with things
> > like name conflicts, scoping, and versioning.  I want to wait until we've
> > got something decent happening for the types, because we should,
> > hopefully, be able to use the same infrastructure for roles (make 'em
> > meta-types or something).
> Sounds good to me. We could also add in meta-info for roles so that we can
> specify converter as a type that requires metainfo parameters "source" and
> "destination".

On it's way.

> > In the meantime, using a single name for a role makes dealing
> > with roles heaps simpler.
> I disagree but as long as you put the long names back in there I can live
> with it ;)

You don't agree that using a single name is simpler than using 2 different 
names? (don't forget that the 2 names are not interchangable - you have to 
remember which one you can use where, and know how to map short -> long and 
vice versa).

Anyway, like I said, this wasn't intended to be the final solution, just a 
tidy-up of the way things currently work.

I do think that many of these issues would simply go away if we were to do 
most lookups by work interface (i.e. using a Class object), rather than a 
string 'name' (whever that means).  Then, we could treat the role names as 
human consumable aliases, and not use them programmatically.


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

View raw message