One point to consider. How many projects do you desire to use your
components with?
Now, if your names are specified in the interface with MyComponent.ROLE,
then your component has nothing to worry about--but your interface does.
If in one project your SourceResolver is mapped to "resolver" and in
another project it is mapped to "source-resolver" (both valid under
Stephen's claims), then how do your components resolve that difference?
If you are set to lookup("resolver"), and then try to move the component
to the new project, it won't work because the correct mapping is
lookup("source-resolver"). If you specify a third-party interface like
Cocoon used to for managing role names, it has to be the *same* class.
That makes it difficult to change when you move from project to project.
But let's say Stephen uses the ROLE idiom, but ignores the interface
name
idiom--and Leo does the same thing. They both create a component with
the
ROLE name equal to "foobar", but they have incompatible interfaces.
Hmmm.
The idiom is not so much because it *could* be done other ways, but it
reduces the issues you have to worry about when you reuse components
between projects. ... Unless you like recompiling your components for
each project...
> -----Original Message-----
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 12, 2002 4:27 AM
> To: 'Avalon Developers List'
> Subject: RE: [proposal] avalon 5 ComponentManager interface
>
>
>
>
> > From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> >
> > While interface names may be convenient in the
> > majority of
> > cases - it is not definitive and any attempt to enforce the
> rule will
> > not only introduce unnecessarily constraints on a developer -
> > but will
> > also break existing components with more subtile role/service
> > relationship.
>
> Despite my saying that the role is an interface name, I have to
>
> + agree with Stephen.
>
> + wonder if this is not really a non-issue, with the container
> configuration containing the role -> individual component
> mappings (i.e. you specify in the configuration that when
> the component asks for X, it gets Y. So you can map
> the role "my.Store" or "my-store" to component "my.StoreImpl".):
>
http://marc.theaimsgroup.com/?l=avalon-dev&m=102266947408779&w=2
http://marc.theaimsgroup.com/?l=avalon-dev&m=102260094419459&w=2
+ Say that I still consider a (String,Object) lookup with hint
to be the best. Hint being defined as "if you ignore this,
processing can still continue (but the result may be a bit off)"
and role being "I need this to proceed". So "SSL" is a hint if
you'd *like* to have a SSL connection, but can do with any
connection. It is a role if you can not proceed (for whatever
reason) without a SSL connection.
The role is a String, becuase it is easy to load it from config
files. I tried completely opaque UID:s in my C++ impl of Avalon,
but ended up with the question - OK, so how do I specify this
in a config file? Hints, however, usually comes not from humans
but in the form of request objects etc., that are parsed by
selectors (or equiv.).
/LS
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
