component

[Emperor <Da...@gmx.net>]

> 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? ;)
Thx,
Nils


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: component

[Stephen McConnell <mc...@apache.org>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>