Re: [picocontainer-dev] Parameter names

On Oct 6, 2007, at 8:15 AM, Mauro Talevi wrote:

> Paul Hammant wrote:
>> Well I'll settle for two jars -
>>    picocontainer-2.0.jar
>>    picocontainer-with-names-2.0.jar
>> or    picocontainer-light-2.0.jar
>>    picocontainer-2.0.jar
>> but would *really prefer one*, given I'm feeling this is pretty  
>> fundamental stuff, and that its included does not break the  
>> original design of Pico
>
> IMO, it's a slippery slope we'd be going down.  What's there to  
> stop us bundling in other deps - eg logging?   Or any other  
> dependency, it does not matter.  The fact that it's shaded does not  
> make it any less of a dependency, in that the shading is about the  
> packaging.
>
> I don't see the need nowadays of bending backwards to ensure we  
> have a *single* jar.  Most people use a plethora of dependencies  
> (often via a transitive dependency a la maven), so one more or less  
> is not going really make or break anything.  I'm all for offering  
> people choice and we should offer the option of named parameter  
> access.  If people want to use it, it's all too easy to do so and  
> more "declarative".
>
>> Without that concession, the logical conclusion is to have all  
>> trace of PN access removed from Pico core, and moved to an  
>> external jar, that would have to be used like so -
>>    new DefaultPicoContainer( .... , new ParameterNameAcessor() );
>> or    new ParameterNameAcessingPicoContainer( ....  );
>
> The idea of abstracting the parameter name access via an accessor  
> interface seems the best approach to me.  Then we can have  
> paranamer-based impl of the accessor.
>

show me example code of it in use ?


> Back to the artifact names, I would go with first option, keeping  
> picocontainer without deps and adding a new artifact (-with-names  
> or -paranamer) with bundled dep.
>
> Cheers
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>


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

    http://xircles.codehaus.org/manage_email