Re: [picocontainer-dev] ArgumentativePC, addConfig() & use names fate ( comments welcome )

Konstantin,

finally got around to your latest config-related commits.

Here are some comments:

Konstantin Priblouda wrote:
> Hi all,
> 
> I just finished config adapter
> (o.n.config.ConfigAdapter)
> which transparently converts strings to java objects
> ( using xstream value converters under covers ) 

First off, I think you mean ConfigParameter.

Next, while I understand the logic of putting in Nano - given the XStream dependency - I would see 
the *PropertiesPC better in Pico Gems, since they are optional and we do have lots of optional 
dependencies in Gems.

So IMO, the *PropertiesPC could go in o.p.g.containers and ConfigParameter and XStreamConverters 
(see below) in a new package o.p.g.parameters (which mirrors the o.p.parameters one).

XStreamConverters:  I really don't like the static nature of ConverterUtils.  In its place, I would 
have something like

public class XStreamConverters {

   private SingleValueConverter[] converters = converters;

   public Converters(com.thoughtworks.xstream.converters.SingleValueConverter... converters){
	this.converters = converters;
   }

   public SingleValueConverter getConverter(Class clazz) {
    	// as currently implemented
   }
}

This class can easily be instantiated with the desired converters, and it can be injected in the 
ConfigParameter as a ctor dependency.

> Does not it makes APC a bit obsolete? (at least part
> of it functionality with converting strings to ints or
> booleans) 
 > The same with addConfig()

As argued by Paul, the idea of APC is to provide a dependency-less impl, which can happily co-exist 
with the *PropertiesPC.

> And as component adapters multiply, I would propose
> refactoring - sprlit ComponentParameter to
> ExplicitParameter (resolutione xplicitely by key, user
> has to specify this) and ImplicitParameter ( resolve
> by type, created implicitely) 

Would be quite a major refactor - what are the benefits?

> and do we really need "useNames"? is there real and
> common use case for this?

It's related to Characteristics.USE_NAMES and the use of Paranamer.

Cheers


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

    http://xircles.codehaus.org/manage_email