> > From: Stephen McConnell <[EMAIL PROTECTED]> > Date: 2004/01/17 Sat PM 03:00:37 EST > To: Avalon Developers List <[EMAIL PROTECTED]> > Subject: Re: [proposal] say no to ROLE (was Re: Re: Roles and Components in > Merlin...) > > 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.
Understood so leave it there. > > 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. Exactly. I should have read this email before responding. > > 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. Ok so then Aaron you were referring to how a container developer interprets or uses the ROLE pattern? In that case we just need not use it or referrence it ever again leaving existing excalibur components as they stand. All future developer need not ever use the ROLE thingy again and our users (component developers) need not worry about defining ROLE. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
