> 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]>
