Re: [picocontainer-dev] Parameter names

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.

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