avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [proposal] say no to ROLE
Date Sat, 17 Jan 2004 23:21:58 GMT
                     == 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.

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).

ROLE is useful and has been in use for years.

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.

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.

Being Against ROLE Is Silly
---------------------------
Reasons for any kind of deprecation that I've seen so far:

  1) it is silly
  2) the future is metadata
  3) the contract surrounding ROLE is not fully specified (it is not
     "computationally clean")
  4) merlin does not use it
  5) it is not required to write a component

my response to each of those:

  1) well, that's a qualitive assertion which I think is silly to make!
  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.
  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)

My Position, Clarified
----------------------

I'm perfectly fine with updating documentation concerning our containers 
that explain that they don't parse nor do anything with ROLE fields, 
that ROLE fields are not part of the 'official' Avalon-Framework 
contract, etc etc. But I'm against removing explanations surrounding 
their usage or recommendations to not include them in work interfaces, 
and I'm even more opposed against making general statements like "you 
should use metadata instead" or "ROLE fields are silly". The use of ROLE 
fields can be quite convenient, and including them makes components just 
a little bit more portable.

In summary:

-1 to "getting rid of ROLE".

My Message, Clarified
---------------------

digressing a little...

For anyone wondering whether I'm mad or agitated; don't worry. I just 
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 
(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 
application to use it, based on the official documentation!!! 
%^@*%@(*$!". Which, needless to say, is an impression to avoid.

cheers!

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett



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


Mime
View raw message