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

Konstantin Priblouda wrote on Friday, September 21, 2007 8:41 AM:

> --- Paul Hammant <[email protected]> wrote:

[snip]

>> See
>> 
> http://blog.decaresystems.ie/index.php/2007/06/14/juicy-code-with-
>> 
>> google-guice-part-4/ - search in page for 'binding
>> annotations will
>> help us'.
>> 
>> I don't like it, but think we should do it too :-(
> 
> I dislike it either. Biggest problem with annotations
> is that they can not be changed afterwards. And that
> we
> (are supposed to) do not have access to source code.
> 
> And whole annotation stuff blows up if you need 2 of
> same with different confiuration -> in this case you
> need second mechanism, so why have annotations first?

Yep. Accessing two different SOAP services is not un unusual scenario.

>> I do like the simplicity and terseness of the
>> parameter-name way
>> we're currently doing, but Jorg highlights a
>> shortcoming that the
>> binding-annotations route does not have.
>> 
>> More customizable parameter name use
>> 
>> What if we also allow the following syntax :-
>> 
>>      pico.addConfig("jdbc_username", "fred");
>>      pico.addConfig("soap_username", "wilma");
>>      // etc
> 
> I would  rather drop addConfig - as this is just a
> string constant without any special meaning (for now)
> - so we do not need new methods to add it.

+1

>> pico.as(USE_NAMES("jdbc_")).addComponent(JDBCService.class);
>> 
>> 
> pico.as(USE_NAMES("soap_")).addComponent(SOAPService.class);
>> 
>> That's about an hour's work on the current codebase.
>> 
>> 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);

>> ... where with is also a varargs Parameter array
>> thing and functions
>> like 'as' ... on the next addComponent(..) only.
> 
> ... what is the difference with
> addComponent(key,class,parameter... ) ?
> ( except yet another object which will call this under
> the hood )

resolves to:

pico.addComponent(JDBCService.class, new NamedParameter("username", "paul :)"), new NamedParameter ("password", "p1"));
pico.addComponent("Foo", SOAPService.class, new NamedParameter("username", "dick"), new NamedParameter ("password", "p2"));
pico.addComponent("Bar", SOAPService.class, new NamedParameter("username", "harry"), new NamedParameter ("password", "p3"));

Well, this is syntactic sugar, the "with" DSL struct must build the Parameter array in this case.

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 ... ?

- Jörg

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

    http://xircles.codehaus.org/manage_email