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?
Statics do not inherit. What the compiler does is make it *look* like it inherits (i.e. it allows you to call a subinterface.ROLE when the subinterface does not mark it).
Any time you have a new contract, i.e. a new interface that extends existing contracts, it is in itself a new ROLE. You should define the .ROLE constant for that interface.
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.
There isn't strong pros for it any more if you assume the full use of meta info, but then again, there aren't any strong cons either if you assume backwards compatibility and ease of portability.
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?
As long as you make sure all the supported containers don't need it, then its use can be discouraged.
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.
I will say this:
lookup(Interface.ROLE);
lookup("interface");Which will let the compiler tell you that you made a typo before you try to run it?
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?
Rely would be too strong. More like it takes advantage of it if you desire.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
