avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Re: [proposal] say no to ROLE
Date Sun, 18 Jan 2004 00:18:31 GMT
Well Leo that's a long azzed email man!

>                      == Don't Say No To ROLE ==
> I Am Pro-ROLE
> -------------
> I have used and written dozens of components that define ROLE, and it 
> has always worked perfectly for me.

Yeah it costs me nothing to really include it.  It's just a prick 
at my side for a few reasons.  Interface extension makes is a not
so optimal solution.  Also if my class derives from multiple service
interfaces then which one is the authoritative ROLE?  See where I'm
going with this?

Meta data solves the need to mark a component as one and puts this
info in the right place: on the implementation.  I think there was 
a use at one point to the ROLE constant but the drive for it is no
longer there IMHO.  But then again I may be full-o-kaka - I don't
have strong feelings about it to tell you the truth.

> I have used and written containers and introspection utilities that 
> attach more meaning to the existence and usage of ROLE members.
> ROLE is not quite equivalent to getClass().getName() because that is 
> subject to change in subclasses (you might have sub-work-interfaces, and 
> you can't have those with public final static String ROLE, which is a 
> good thing).

Right but it makes ROLE more limiting I think.

> ROLE is useful and has been in use for years.

So has the fireplace but we don't all cook on it :-).  This IMO is
not a reason at all for keeping it.  Also note that the jcontainer
folks of done away with ROLE as well.  I know Peter Donald et. al. 
threw it out the window with Loom the first chance they got.  Is ROLE
required for Pico?

> The main useful thing about ROLE for me is that you define it in the 
> work interface, and even in deep inheritance it is always clear (because 
> its 'lightweight forced') what exactly constitutes the work interface.

Forgive me but you lost me here.  Ok inheritance actually complicates the
picture I think.  IMO any interface can be deemed a service interface if 
a component says here use this as my service interface when you expose me
to the world right?  That's what the meta tags do.  Someone correct me if
I'm wrong.

> It saves several characters of typing in each sm.lookup() and is also 
> more readable and conceptually more clear than getClass().getName().
> It serves as lightweight decoupling between the ROLE concept and an 
> implementation type, without using a non-OO way to communicate role 
> names between components.
> That is quite a few arguments for keeping it around.

Not for me but I don't feel as strongly as you do so I don't 
think I'll push the point further.  I simply don't agree but
again no biggy.

> Reasons for any kind of deprecation that I've seen so far:
>   1) it is silly

Never thought it was silly just a vestigial structure we don't

>   2) the future is metadata

Yeah I thought so.  Could you elaborate why meta data does not
obviate the use of ROLE.

>   3) the contract surrounding ROLE is not fully specified (it is not
>      "computationally clean")

I have not made this claim but I don't know what ROLE is used for
other than branding the service interface through which a component
is exposed to the world by a container.  The @service tag here is 
what makes ROLE moot I thought:


Here I can label the component as supporting 1 or more service 
interfaces.  Why would I want to use ROLE?  It gets confusing 
making the user community ask us a bunch of questions no one 
can or wants to answer.

>   4) merlin does not use it

Yeah it does not.  Perhaps demonstrating the fact that it has
evolved to a higher plane.  Again why use ROLE when you don't
have to today.

>   5) it is not required to write a component

Why bother if it is not required?

> my response to each of those:
>   1) well, that's a qualitive assertion which I think is silly to make!

... just think its the old timer way o doin things

>   2) also disagree with that, the success of stuff like pico and spring
>      shows that the future is not neccessarily "metadata". Besides,
>      in general, the general argument that "the future will be different"
>      is a bad one...backwards compatibility is usually a good idea.

I agree about being backwards compatible.  So does Pico rely on ROLE?

>   3) the contract surrounding any particular ROLE member is that the
>      interface that declares it, the implementations of that interface,
>      and the users of those implementations all know what it means; there
>      is no need for specifying anything else
>   4) I don't use merlin :D; besides, merlin *can* 'use' it (evidenced by
>      the fact that I can put components that use ROLE fields inside
>      merlin)
>   5) it is not required to not write it to write a component either; in
>      other words, this is not a real argument at all. Going further, it
>      is trivial to create and maintain ROLE fields and it makes a
>      component just a little bit more portable (which is a Good Thing)

Perhaps #5 is the most compelling reason to keep it.  If Pico I think uses 
ROLE there is also another reason why it might be worth keeping.

> -1 to "getting rid of ROLE".
> For anyone wondering whether I'm mad or agitated; don't worry. I just 

NP dude you feel strongly and that's cool - I don't always think
people are mad or else I'd think Niclas was mad all the time.  Just
kidding Nic.

> come on strong to set something straight ASAP :D. But I've seen avalon 
> suffer from these kind of "change for the sake of change" things before 

Please I would not do that - hope I don't give you that impression.

> (we did silly things like slap @deprecated on Component a few times to 
> often :D). Everyone is entitled to an opinion, but you also have a 
> responsibility to not scare people. Joe User might now think "WTF? I 
> shouldn't use ROLE? It's silly? But I've just updated all of my 

I think they're saying things like WTF when ROLE looks vestigial to
them.  Why ROLE when I have @service?  What happens to ROLE when one 
service interface extends two other service interfaces?  ROLE has issues
to our user community I feel and getting rid of it may not be a bad
idea to clarify these matters to our users.

> application to use it, based on the official documentation!!! 
> %^@*%@(*$!". Which, needless to say, is an impression to avoid.

Exactly my reasoning for axing it.  But if one person is not cool
with it then I won't push further.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message