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

--- Mauro Talevi <[email protected]> wrote:

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

Exactly.  I was still under impression of idea (sice
dropped ;) ) of config adapter.

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

PropertiesPC could as well go into core - it does not
need any external dependencies at all - like APC

> 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).
... and ConfigParameter went into nano because it
already got xstream dependency. 

( and as means of configuring and rigging up
application, it could be well right place )

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

That's a matter of discussion - we could provide 
static default provider ( which suffices for most
puproses ) and allow to configure it. 


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

PropertiesPC is dependencyless, and APC in current
implementation is not very usefull ( only strings, 
booleans and integers ) - and all his special
functionality is covered by component parameter - 
and even more flexibly. 
( ComponentParameter allows to referr the same config
entry i.e either as int or float.  or string / url ) 


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

I would not say so.  It s kind of splic current
component adapter in explicit ( by key ) and implicit
one (by type). At the moment usage by key is done
implicitely, while usage by type is used behind the
scenes when hunting for greediest constructor. 

Benefit would be simplier constructors, and also 
logic inside parameter ( hunting for dependency ) 


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

I find current usage of it quite misleading.
 - it produces "ambiguous" error when nothing found - 
but it really should be "not found"
 - while it does introduce optional dependency to core
( asm / paranamer ) it also puts burden on components
being managed ( they have to be processed by
paranamer, or behold debug information - which is not
that 
common) - and this is quite limiting usefullness of
feature. 

IMHO, depending on configuration entry shall be always

explicit - or you will get serious security problems
with injection of some bullshit. 

That's why ConfigParameter does not resolve by type - 
only by key. 
> Cheers

Cheers. Today is day 0x100 of a year, and thus
inofficial programmers appreciation day ;)

Congratulations to all 

regards,

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


       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

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

    http://xircles.codehaus.org/manage_email