Re: [picocontainer-dev] Simplify PIcoConatienr interface/ Refactor parameter[s]

On Nov 16, 2007, at 11:06 AM, Konstantin Priblouda wrote:

>
> --- Paul Hammant <[email protected]> wrote:
>
>> Its most definitely a hack - am interested in an
>> elegant successor.
>>
>> The ParameterName interface is to allow a lazy
>> lookup of a parameter
>> name (arguably costly) without affecting
>> performance.  The majority
>> case for Pico will be looking up by type (as
>> always), the minority
>> use will be by parameter name.
>
> It looks to ma, that scopes / phases are mixed here.
> specifying parameter lookup etc ( i.e.  wiring )
> definitely belongs to  composition phase.

as in - at time of registration?

>
> Looking up component shall be comlpetely agnostic
> of container buildup (and produce comparable results
> for subsequent invocations).
>
> What is going to happen on second subsequent
> invocation?  If component is already instantiated
> and cached - additional parameters will be not
> honored.
> ( and this is not transparent to user )

its cached per component adapter instance.

>
> And method in question belongs to retrieval of
> component adapter in question. Shall it be some proxy?
> Will this adapter be affected by name hint?

only if USE_NAMES is specified during the registration/adding of the  
comp.

>
> Will it affect adapter resolution?
>
> As for lazy lookup - to profit from this,
> ParameterName shall be reused somewhere.
> Who is going to reuse this?  Typically ParameterName
> would refer to certain ( the same ) adapter - so why
> not keep adapter itself?

The lazy nature is to prevent the parameter name being looked up for  
a component that is going to have all deps injected by type - in that  
scenario it would be unecessary and costly to look up param names.

Thus ..

     public  <T> T resolveInstance(PicoContainer container,    
ComponentAdapter adapter, Class<T> expectedType, ParameterName  
expectedParameterName, boolean useNames) {

is 100x better than ..

     public  <T> T resolveInstance(PicoContainer container,    
ComponentAdapter adapter, Class<T> expectedType, String  
expectedParameterName, boolean useNames) {

>
>
>
>> Incidentally, we need to put in the binding
>> annotations thing too,
>> sooner or later.  It's in the same space:
>>
>>      class CompA {
>>        public CompA(@JdbcUserName String name,
>> @JdbcPassword String
>> password) { }
>>      }
>>
>> Dreadfully verbose, but definitely something a
>> versatile embeddable
>> container should do.
>
> Who is going to define such annotations? If we are
> speaking of hints ( for lack of param names ) there
> shall be generic annotation to do this...
> ( what versatiliy we are speaking of otherwise? )

There's no generic annotation - the component writer invents their  
own annotations.  Guice does this (but I find it to be incredibly  
verbose, and it screams you 'use the parameter name instead').

Look for @MyAnnotation in http://java-x.blogspot.com/2007/03/my-first- 
guice-web-application.html

Guice has a base annotation, but it should not really be needed.


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

    http://xircles.codehaus.org/manage_email