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

Konstantin Priblouda <kpriblouda-/[email protected]>
Newsgroups gmane.comp.java.picocontainer.devel
Message-ID <[email protected]>
--- Paul Hammant <[email protected]> wrote:

> Folks,
> 
> >
> > You still have the problem that parameter names
> have no scope for  
> > the component:
> >
> > class JDBCService {
> > 	JDBCService(URL endpoint, String username, String
> password);
> > }
> >
> > class SOAPService {
> > 	SOAPService(URL endpoint, String username, String
> password);
> > }
> >
> 
> So Guice has 'binding annotations' for this.  It is
> very verbose.
> 
> 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? 


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

>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

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

> - Paul


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


       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

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