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

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

> >> 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 )
> 
> Yes - I get the reason.  But since Gems contains
> classes with optional dependencies, there is no 
> real reason to have in Nano, which IMO is more
> suited for the scripting layer.

Properties stuff is basically the same as APC - 
they could be merged together with  a pair of 
additional constructors. 

The only difference is automatical conversion
to int / boolean in APC ( which is IMHO obsolete ) 

> >>
> >> 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. 
> 
> Rather than static, I see more the benefit of a
> non-static default ctor of XStreamConverters, which 
> will hold a list of default converters (passed to
> the non-default ctor).

There has to be kind of singleton, or at least reusing
this provider, as we are building relations between
classes and converters and cache this information. 

we also can say that resolvong configuration is
one-time job and does not require such caching - 
but I do not like idea of wasting processor clocks. 

> > 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
> ) 
> 
> 
> The main difference is that it deals with string
> argument input rather than Properties objects.
> Again, no reason, they can't both coexist or have
> APC adapt. PropertiesPC

This difference can be easily covered by constructor
( properties by itself are the same as array of
strings
with defined separator  to split them ) 

regards,

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


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

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

    http://xircles.codehaus.org/manage_email