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 componentmy 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!!! [EMAIL PROTECTED]@(*$!". 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
