Peter Royal wrote:
>On Tuesday 11 June 2002 09:27 am, Berin Loritsch wrote:
>
>
>>The decision stems from the best way to have a unique name for a role,
>>without being subject to naming clashes. It would be really bad and
>>
>>
>
>I've always viewed it as a "best practices" method for naming roles. Roles
>don't *have* to be named after their interfaces but its easy enough to do and
>makes sense.
>
>imho, Stephan was balking at "role name == interface name" as a concrete
>truth for Avalon Framework. Its not, its just highly recommended.
>-pete
>
>
Actually, I'm balking at both!
The notion of "highly recommended" seems to me to be simply an unfounded
recommendation - it's subtle reinforcement that this "best practice". I
do not see any grounds for declaring this a "best practice" - in fact I
believe it is the opposite!
Roles (at the level of abstraction of the framework) are unique within
the scope of the component that declares them. It's simply that simple.
This issue is that a "best practice" or the classification of something
as "highly recommended" contributes to the belief that role names are
more than simple strings, unique within the scope of a particular
component type that are used for nothing more than an opaque key to a
service instance. Diverging from opaque keys without rigorouse
supporting semantics is just plain "bad". I would accept that "we" have
"traditionally" used the convention of interface class name for a role
name but as we all know - "tradition" does not mean "best practice", no
matter how highly recommended a particular tradition is said to be.
The real "best-practice" is for a component to manage its own namespace.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
