Emperor wrote:
> > > Leo Simons wrote: > > > > > > a few observations: > > > > > > - we no longer like ComponentManager/Selector?? > > > > More specifically we don't like "Component" as a type constraint on a > > method parameter. > > > > Hmm... Could you explain that? ;) If you have an operation like the following: Component lookup( String name ); or public void addComponet( Component component ); you have a problem. It means that you are constrained in terms of the objects that the implementation can return. In the case of Component, the interface does not declare any operations - which means that any "component" MUST implement the Avalon Component interface. This conflicts with real work requirements (in particular the situation where organisations such as the OMG and other bodies are providing standards for components and those standards are dictating the interface that are generated). For example, I have CORBA remote objects and local valuetypes that are generated by a IDL compiler that are real "components" but they don't implement the Avalon Component interface. The ComponentManager and related interface as they stand require that real "components" are wrapped in a holder that implements "Component". This results in unnecessary packing and unpacking of objects just so these objects can be managed using the Avalon framework. Retracting Component as per the new ServiceManager/Servicable interfaces solution opens up Avalon to the rest-of-the-world. Cheers, Steve. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
