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