RE: [picocontainer-dev] Preferring Parameter names.....

Konstantin Priblouda <kpriblouda-/[email protected]>
Newsgroups gmane.comp.java.picocontainer.devel
Message-ID <[email protected]>
--- Jörg Schaible <[email protected]>
wrote:

> >> An alternative using Parameter objects
> >> 
> >>      pico.addComponent(JDBCService.class);
> >> 
> >> or ..
> >> 
> >>      pico.with(new
> NamedParameter("jdbc_username"), new
> >> NamedParameter
> ("jdbc_password")).addComponent(JDBCService.class);

> > 
> > Somehow I prefer this syntax, as it promisses
> simplier
> > parameter API
> 
> What I don't understand: With that call we have
> exaclty the scope we need!
> 
> pico.with(new NamedParameter("username", "paul :)"),
> new NamedParameter ("password",
> "p1")).addComponent(JDBCService.class);
> pico.with(new NamedParameter("username", "dick"),
> new NamedParameter ("password",
> "p2")).addComponent("Foo", SOAPService.class);
> pico.with(new NamedParameter("username", "harry"),
> new NamedParameter ("password",
> "p3")).addComponent("Bar", SOAPService.class);

I think referring to formal parameter name is not for
pico proper, as it does not conform to pure vanilla
java and requires additional  (and not obvious) 
processing of target classes or compiling them with
debug info (may be unavailable) 



> Weird thought: What if we drop the Parameter
> altogether? In the end it acts like an intelligent
> map ... why not use a simple Pico instead? If each
> component has its own private Pico that has the main
> container as parent, the lookup is transparent and
> you can add parameters as instances without the
> problem that they interfere with parameters of the
> others? The DPC might be too heavy weight, but if we
> provide a SimplePC ... ?

I like current work distribution - container is
storage, provides lifecycle and hierarchy, component
adapters provide configuration and instantiation
behaviour and rely on parameters to obtain
dependencies.

We already have:
 - by key parameters 
 - by type
 - config ( by key / convert type ) 
 - jndi ( get from ) 
 - jmx ( get from ) 

Put everything in pico? Too heavy. I think we are
better off with  aggregation, as it provides simple
components. 

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.