You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/01/17 18:40:35 UTC
[proposal] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
Sorry dude thought I had the dev list there.
ALex
>
> From: Stephen McConnell <mc...@apache.org>
> Date: 2004/01/17 Sat PM 12:39:19 EST
> To: Avalon framework users <us...@avalon.apache.org>
> Subject: Re: [vote] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
>
> Alex Karasulu wrote:
>
> > Guys,
> >
> > What do you say to just getting rid of this silly ROLE constant?
> > If Merlin does not use it and we have Avalon meta for the tagging
> > of components then why bother with ROLE I say. Let's get rid of
> > it once and for all making it official here:
> >
> > [X] Say no to ROLE constant
> > [ ] Keep it
>
> This is really a subject for the dev list - do you want to repost?
>
> Stephen.
>
>
> --
>
> |------------------------------------------------|
> | Magic by Merlin |
> | Production by Avalon |
> | |
> | http://avalon.apache.org/merlin |
> | http://dpml.net/merlin/distributions/latest |
> |------------------------------------------------|
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@avalon.apache.org
> For additional commands, e-mail: users-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in
Merlin...)
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-01-17 at 20:00, Stephen McConnell wrote:
> > What do you mean by "say no"? Are we going to change all excalibur
> > components which have it?
>
> That's not an option so long as there are ECM users out there. But
> "saying no" can be interpreted as deprecating the usage pattern.
Yep. And that was partly what I wanted to point out.
> > Are we going to put disclaimers in the
> > documentation that say "don't do it this way"? Or modify all
> > documentation?
>
> I think we need to purge the notion from the documentation.
I think that could be a good thing. Especially if it is causing
confusion.
It's all part of the process of moving away from ECM and on to better
things.
> > The ROLE thing was really just a shorthand, a shortcut. In general it's
> > equivalent to MyService.class.getName(); or the fully qualified
> > classname of the service in question.
>
> But its not necessarily the same. I remember a long time ago raising
> the same subject and it was explained to me that the string returned by
> ROLE need not be the same as the interface classname. Anyway, I've never
> managed to get a clean computationally answer on the ROLE question.
A computationally correct definition of ROLE? Don't think it exists.
Or I should say, it probably existed in ECM days, but is slightly out of
place now. I'm certainly a +1 on cleaning up the semantics of ROLE and
other related lookup issues. Consistency in these basic definitions is
something I think we're all looking for.
I just wanted to make sure we all understand what "saying no" to ROLE
means. If it means removing it from documentation and clearing up it's
use in existing code (ie- Excalibur), then I'm all for it. If it means
removing it from the code or removing lookups via type or classname
(which is essentially what most uses of ROLE are) as opposed to alias,
then I have some concerns.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in
Merlin...)
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
> On Sat, 2004-01-17 at 17:40, Alex Karasulu wrote:
>
>>Sorry dude thought I had the dev list there.
>>ALex
>
>
> No problem.
>
> I have a couple questions though.
>
> What do you mean by "say no"? Are we going to change all excalibur
> components which have it?
That's not an option so long as there are ECM users out there. But
"saying no" can be interpreted as deprecating the usage pattern.
> Are we going to put disclaimers in the
> documentation that say "don't do it this way"? Or modify all
> documentation?
I think we need to purge the notion from the documentation.
> The ROLE thing was really just a shorthand, a shortcut. In general it's
> equivalent to MyService.class.getName(); or the fully qualified
> classname of the service in question.
But its not necessarily the same. I remember a long time ago raising
the same subject and it was explained to me that the string returned by
ROLE need not be the same as the interface classname. Anyway, I've never
managed to get a clean computationally answer on the ROLE question.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in
Merlin...)
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-01-17 at 17:40, Alex Karasulu wrote:
> Sorry dude thought I had the dev list there.
> ALex
No problem.
I have a couple questions though.
What do you mean by "say no"? Are we going to change all excalibur
components which have it? Are we going to put disclaimers in the
documentation that say "don't do it this way"? Or modify all
documentation?
The ROLE thing was really just a shorthand, a shortcut. In general it's
equivalent to MyService.class.getName(); or the fully qualified
classname of the service in question. This was perhaps more important
in the ECM days, but in all three modern containers, the service name
can be just about anything. If you're client component doesn't really
care which implementation of a service it gets, using the service
classname seems like a reasonable solution. It says to the container,
"Look, just get me an implementation of this service."
Also, it's one thing to get rid of the ROLE constant and just tell
people to use MyService.class.getName(). It's another to suggest that
the semantics for ServiceManager lookup need revised (they do, but it's
a whole different issue) [1].
Don't want to cause any commotion, just want some clarification.
--
jaaron <http://jadetower.org>
[1] http://wiki.apache.org/avalon/ServiceManager
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Berin Loritsch <bl...@apache.org>.
Neeme Praks wrote:
>
>
> The reason here is that the two work interfaces are very closely
> related, but nevertheless they are two different interfaces and it would
> be undesirable to merge the two interfaces. My current workaround (with
> Fortress) is to separate the interfaces and to use
> DelegatingTimeProvider as the TimeProvider implementation:
>
> public interface TimeProvider {
> final static String ROLE = TimeProvider.class.getName();
> Date getTime();
> }
>
> public interface MutableTimeProvider {
> final static String ROLE = MutableTimeProvider.class.getName();
> void setTime(Date time);
> }
>
> public class DelegatingTimeProvider implements TimeProvider, Serviceable {
> private MutableTimeProvider timeProvider;
>
> public Date getTime() {
> return this.timeProvider.getTime();
> }
>
> public void service(ServiceManager sm) throws ServiceException {
> this.timeProvider = (MutableTimeProvider)
> sm.lookup(MutableTimeProvider.ROLE);
> }
> }
>
> But this is not very elegant and requires the component developer to
> always write a delegating implementation whenever he/she wants to
> achieve this effect. And the whole issue becomes many magnitudes more
> complex when we increase the complexity of the inheritance hierarchy
> just a bit.
As an FYI, static values do not inherit. They are scoped by the enclosing
interface. So in your example:
public interface TimeProvider {
String ROLE = TimeProvider.class.getName(); // always static final
}
public interface MutableTimeProvider {
String ROLE = MutableTimeProvider.class.getName(); // always static final
}
Will get the results you want without having to do all the workaround junk.
The value MutableTimeProvider.ROLE is different than the TimeProvider.ROLE.
Also, note that by using inheritance, you are essentially saying that all
MutableTimeProviders are TimeProviders and can be used accordingly. You are
not implying that all TimeProviders are MutableTimeProviders, as that would
not be the case. That is the contract you are introducing into your system,
and that should be well understood regardless of what lookup value you use
to get the TimeProvider.
There is no need to use delegating time providers, etc.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Neeme Praks <ne...@apache.org>.
Leo Simons wrote:
[snip]
>> The ROLE is part of the PLAY. The Actor performs the Role. The Same
>> Actor (read component) can perform (in a theatrical play) Any Role of
>> the Play. The Actor's interface (in a theatrical play) is his/her
>> experience/training/understanding of Acting, so that the director can
>> issue directives like "be more subtle in the expression of grief"
>> (which I, non-Actor, wouldn't have a clue what that would mean).
>>
>> I can't see how this is the case with Avalon Roles. Is the PLAY
>> restricted to a single interface and a single Role? Probably not.
>> Then if a bunch of interfaces makes the Play, then I can't swap the
>> actors to play the different roles. In fact, it is like saying one
>> particular actor can only play one type of Roles.
>
>
> yep.
>
>> But then, someone will say, a component can implement many different
>> interfaces and by that play many roles
>
>
> yep, but that's a bad idea. A component should do one thing and do it
> well.
I've had the use case for a component with more than one work interface
and I support the idea of enabling their use... Example:
public interface TimeProvider {
Date getTime();
}
public interface MutableTimeProvider extends TimeProvider {
void setTime(Date time);
}
The reason here is that the two work interfaces are very closely
related, but nevertheless they are two different interfaces and it would
be undesirable to merge the two interfaces. My current workaround (with
Fortress) is to separate the interfaces and to use
DelegatingTimeProvider as the TimeProvider implementation:
public interface TimeProvider {
final static String ROLE = TimeProvider.class.getName();
Date getTime();
}
public interface MutableTimeProvider {
final static String ROLE = MutableTimeProvider.class.getName();
void setTime(Date time);
}
public class DelegatingTimeProvider implements TimeProvider, Serviceable {
private MutableTimeProvider timeProvider;
public Date getTime() {
return this.timeProvider.getTime();
}
public void service(ServiceManager sm) throws ServiceException {
this.timeProvider = (MutableTimeProvider)
sm.lookup(MutableTimeProvider.ROLE);
}
}
But this is not very elegant and requires the component developer to
always write a delegating implementation whenever he/she wants to
achieve this effect. And the whole issue becomes many magnitudes more
complex when we increase the complexity of the inheritance hierarchy
just a bit.
So my suggestion would be: allow simple things be simple and complex
things possible (similar to the PERL slogan). Leo has a point about the
simplicity and enforceability of the ROLE strings. Alex also has a point
about the extended capabilities of the meta solution. So how about we
just document both approaches and highlight pro's and con's of both? So
the recommended approach depends directly on the container where we plan
to deploy the component. And if we need cross-container compatibility,
just add in both: ROLEs and meta-data.
(and it would be about time to meta-enable fortress, but that is
entirely separate thread...)
Rgds,
Neeme
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> On Saturday 17 January 2004 15:21, Leo Simons wrote:
>
>>I Am Pro-ROLE
>>-------------
>>I have used and written dozens of components that define ROLE, and it
>>has always worked perfectly for me.
>
>>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.
>
> Could you elaborate on this a bit?? I have probably asked this before, and I
> have yet to see the light.
Well, the point I made above is:
public interface WorkInterface
{
public final static String ROLE = WorkInterface.getClass().getName();
doStuff();
}
public interface SuperWorkInterface extends WorkInterface
{
// error: public final static String ROLE =
// WorkInterface.getClass().getName();
doMoreStuff();
}
public class MyComp implements SuperWorkInterface
{
// ...
// compiler error: public final static String ROLE =
// WorkInterface.getClass().getName();
}
public void service( ServiceManager sm )
{
WorkInterface wi = (WorkInterface)sm.lookup( WorkInterface.ROLE );
// error: SuperWorkInterface wi =
// sm.lookup( SuperWorkInterface.ROLE );
// error: SuperWorkInterface wi =
// sm.lookup( MyComp.ROLE );
// no error:
WorkInterface wi = (WorkInterface)sm.lookup(
WorkInterface.ROLE );
if( !(wi instanceof SuperWorkInterface) )
log.warn("Degraded service!");
}
you might say using ROLE discourages sub-work-interfaces, or at least
somewhat 'forces' clients to be aware of the hierarchy (everyone can
ignore it, but its there). With a pure getClass().getName(), this is not
the case:
public void service( ServiceManager sm )
{
// more typing!:
WorkInterface wi = (WorkInterface)sm.lookup(
WorkInterface.getClass().getName() );
// ServiceException (only found at runtime):
SuperWorkInterface wi =
sm.lookup( SuperWorkInterface.getClass().getName() );
// ServiceException (only found at runtime):
SuperWorkInterface wi = sm.lookup( MyComp.getClass().getName() );
}
> Concretely; The analogy often brought up is the cast at a theatrical play. The
> play consists of Roles. There are any number of Actors. Each actor plays one
> or more roles. This setup is clear, now...
> In Avalon, the Role is the ROLE, and the Actor is the component.
>
> Does anybody find the fault in the logic/analogy above?
yep. Analogies are flawed by definition :D
> The ROLE is part of the PLAY. The Actor performs the Role. The Same Actor
> (read component) can perform (in a theatrical play) Any Role of the Play. The
> Actor's interface (in a theatrical play) is his/her
> experience/training/understanding of Acting, so that the director can issue
> directives like "be more subtle in the expression of grief" (which I,
> non-Actor, wouldn't have a clue what that would mean).
>
> I can't see how this is the case with Avalon Roles.
> Is the PLAY restricted to a single interface and a single Role? Probably not.
> Then if a bunch of interfaces makes the Play, then I can't swap the actors to
> play the different roles. In fact, it is like saying one particular actor can
> only play one type of Roles.
yep.
> But then, someone will say, a component can implement many different
> interfaces and by that play many roles
yep, but that's a bad idea. A component should do one thing and do it well.
> I am more against the terminology (ROLE) than I am against the use of String
> as lookup, and Leo's version of encoding lookup information into that String.
> I also know that the terminology has been around quite a while, but that
> doesn't mean it is good (compare War).
+1
--
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
Re: [proposal] say no to ROLE
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 15:21, Leo Simons wrote:
> I Am Pro-ROLE
> -------------
> I have used and written dozens of components that define ROLE, and it
> has always worked perfectly for me.
> 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.
Could you elaborate on this a bit?? I have probably asked this before, and I
have yet to see the light.
Concretely; The analogy often brought up is the cast at a theatrical play. The
play consists of Roles. There are any number of Actors. Each actor plays one
or more roles. This setup is clear, now...
In Avalon, the Role is the ROLE, and the Actor is the component.
Does anybody find the fault in the logic/analogy above?
The ROLE is part of the PLAY. The Actor performs the Role. The Same Actor
(read component) can perform (in a theatrical play) Any Role of the Play. The
Actor's interface (in a theatrical play) is his/her
experience/training/understanding of Acting, so that the director can issue
directives like "be more subtle in the expression of grief" (which I,
non-Actor, wouldn't have a clue what that would mean).
I can't see how this is the case with Avalon Roles.
Is the PLAY restricted to a single interface and a single Role? Probably not.
Then if a bunch of interfaces makes the Play, then I can't swap the actors to
play the different roles. In fact, it is like saying one particular actor can
only play one type of Roles.
But then, someone will say, a component can implement many different
interfaces and by that play many roles - I say SoC !
I am more against the terminology (ROLE) than I am against the use of String
as lookup, and Leo's version of encoding lookup information into that String.
I also know that the terminology has been around quite a while, but that
doesn't mean it is good (compare War).
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Leo Simons" <le...@apache.org>
> 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.
+1 for that!
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>>> 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).
>>
>>
>> Eliminating the Component interface changed Avalon from being a closed
>> solution to a solution open to the rest of the world.
>
>
> I meant just the '@deprecated'. That was the bad part of the idea. Just
> like the bad part of the idea here is again saying things are silly,
> bad, or deprecated.
Examples of silly:
1. writing a book on "101 reasons why ROLE is a good thing"
2. writing the sequel "101 reasons why ROLE was a good thing"
Example of bad:
1. writing documentation that reference ROLE instead of clearly
showing that a interface class name is being passed as an
argument
2. writing a new component and including ROLE because all the
other components include ROLE or because you copied the
example from Avalon docs
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> Leo Simons wrote:
>
>> 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.
>
> Great - seems to me that your totally in sync. and consistent with the
> views expressed in the other posts on this subject. Let me just clarify
> one point. I presume that you are also OK with the elimination of the
> ROLE pattern within the framework docs?
+1. But I'd like it kept in DwA, for example.
>> 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).
>
> Eliminating the Component interface changed Avalon from being a closed
> solution to a solution open to the rest of the world.
I meant just the '@deprecated'. That was the bad part of the idea. Just
like the bad part of the idea here is again saying things are silly,
bad, or deprecated.
> Mixing in
> meta-info into a service interface is just plain *bad*. ROLE is a
> simply the last vestige of practices that mix meta-info with the
> separate concern of the service computational interface.
nah. ROLE is not meant to be used as "metainfo". The use of ROLE is a
quite simple convention that encourages and enables using the SM as a
dependency injection mechanism as opposed to a service location
mechanism. Whether dependency injection is a good idea is, I guess,
still up for debate, but I think it is :D
--
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
Re: [proposal] say no to ROLE
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> 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.
Great - seems to me that your totally in sync. and consistent with the
views expressed in the other posts on this subject. Let me just clarify
one point. I presume that you are also OK with the elimination of the
ROLE pattern within the framework docs?
> 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).
Eliminating the Component interface changed Avalon from being a closed
solution to a solution open to the rest of the world. Mixing in
meta-info into a service interface is just plain *bad*. ROLE is a
simply the last vestige of practices that mix meta-info with the
separate concern of the service computational interface.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Leo Simons <le...@apache.org>.
== 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
Re: [proposal] say no to ROLE
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 17 January 2004 09:55, Stephen McConnell wrote:
> >[X] Say no to ROLE constant
> >[ ] Keep it
>
> My opinion [X] Say no to ROLE constant - but with some comments.
> Firstly, existing declarations of ROLE have to stay on release products
> for reasons of backward compatibility - and secondly, Fortress is not
> yet meta enabled and is probably using ROLE as a pattern. With Fortress
> updated I think the ROLE pattern can safely retired.
Yes, I agree (I (who else?) never understood it). The ROLE constant is a
recommended pattern, right?
The existing ROLE in all the components must remain!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE
Posted by Stephen McConnell <mc...@apache.org>.
Alex Karasulu wrote:
>Guys,
>
>What do you say to just getting rid of this silly ROLE constant?
>If Merlin does not use it and we have Avalon meta for the tagging
>of components then why bother with ROLE I say. Let's get rid of
>it once and for all making it official here:
>
>[X] Say no to ROLE constant
>[ ] Keep it
My opinion [X] Say no to ROLE constant - but with some comments.
Firstly, existing declarations of ROLE have to stay on release products
for reasons of backward compatibility - and secondly, Fortress is not
yet meta enabled and is probably using ROLE as a pattern. With Fortress
updated I think the ROLE pattern can safely retired.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
Posted by hammett <ha...@uol.com.br>.
> What do you say to just getting rid of this silly ROLE constant?
> If Merlin does not use it and we have Avalon meta for the tagging
> of components then why bother with ROLE I say. Let's get rid of
> it once and for all making it official here:
AFAIK this ROLE constant is used for lookup. What will be your sugestion for
this as replacement?
regards,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [proposal] say no to ROLE (was Re: Re: Roles and Components in Merlin...)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
> [ ] Say no to ROLE constant
> [X] Keep it
Alex,
it's a nice idea, but having ROLE simply works too well.
(If it had been an annoyance, I'd be up for saying no.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org