Well Leo that's a long azzed email man!
:D. Writing short e-mails is more difficult :D
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?
that's exactly why its good. A class that derives from multiple service interfaces is a "suboptimal decomposition". I think that if ROLE is actually getting in the way you need to redo the decomposition :D
Meta data solves the need to mark a component as one and puts this info in the right place: on the implementation.
I do not like multiple service interfaces on an implementation. That's a design choice ROLE helps enforce (as in I get red lines under code in IntelliJ). This is not doable with metadata.
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.
precisely :D
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.
nah. Just like Merlin supports the use, so does Loom :D
Is ROLE required for Pico?
certainly not. Since with Pico there's no lookup() there's no key either.
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.
yes, you can do that, and you should be able to do that. But if you design an application from the ground up around avalon, it is a good idea to be very strict and clear in your choices of "this is a work interface", and "this is not".
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.
good :D
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 need.
well you wrote it was silly :D
2) the future is metadata
Yeah I thought so. Could you elaborate why meta data does not obviate the use of ROLE.
oh, but it does. It is just I'm not convinced that metadata is actually the future ;)
3) the contract surrounding ROLE is not fully specified (it is not "computationally clean")
I have not made this claim
nah, Steve did.
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:
http://avalon.apache.org/meta/meta/info/type/services/index.html
Here I can label the component as supporting 1 or more service interfaces. Why would I want to use ROLE?
there's lots of arguments against using javadocs tags for marking things up. I don't think we should repeat them :D
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.
The point is that there are people who don't use merlin and won't be using it for a long time to come. But the fact that merlin doesn't use ROLE doesn't really demonstrate anything -- ecm, phoenix, fortress don't use it either :D
5) it is not required to write a component
Why bother if it is not required?
see above :D
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?
nope. No container relies on ROLE. But there are applications out there that do.
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.
ROTFL :D. Note I don't feel strongly about ROLE fields at all. I generally never feel strongly about any kind of code, architecture, etc.
I just feel strongly about how we go about managing change to these kinds of things. I saw qualitative assertions like "silly", "bad" etc in use (even on the users list) coupled to what seemed like people eager to make quick decisions to deprecate things without having the full picture.
I think I've given lots of arguments why changing the use or reference to ROLE is bad, and the only argument that holds any kind of weight IMHO is "metadata is better". But we held the metadata-vs-convention debate several times and is as of yet a tie within the java world.
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.
hehehe. I think all programmers have a natural drive to change things. That it is change for the sake of change is always in the eyes of bystanders. The phrase is good among peers to remind us of that! I don't think anyone would consciously do that, ever. But in the eyes of some beholders, it might seem that way.
(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.
Now that's some good arguments! A final sideline on that is that you should consider that its the vocal part of the user community that has these kinds of problems. There's also a large user community out there who don't use @service (don't know it exists, even), aren't looking at the new developments, hence don't have questions. Until they do plan a migration, and they find everything has changed.
application to use it, based on the official documentation!!! [EMAIL PROTECTED]@(*$!". 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.
this ain't about me dude :D. It's about stability!
-- 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]
