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

Also answering on the list ;-)

Konstantin Priblouda wrote on Friday, September 14, 2007 10:38 AM:

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

Mauro's point was the dependency here.

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

Nobody said, that the list of default converters is not a static :)

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

I did not had a look yet at the source, but in general I am no friend for separate solutions for slightly different uses cases. And passing system properties as arguments, building a Properties instance from CLI arguments seem not too different to me. The purpose is the same: Configuring from command line.

Please don't forget, that we have a 3rd case for the key usage. A "type key" also defines precedence resolving types.

Maybe we should take a step back and have a look at what we try to solve. Scenario:

My application uses a JDBC connection and two different web services. Ingoring the security stuff each of those 3 components need at least a URL, two of them are instances of the same class.

It is obviously that parameters are tied to an "instance" and have therefore a very minimal "scope". The Pico 1.x solution was to create a Parameter[] array. There was no need to register such params in a container at all. The solution for named paarmeters was proposed by me using an additional "hint" for the parameter - that's what Shawn also instinctively implemented. Also remember Thomas Heller's AutoParameter that solved the problem to lookup the value elsewhere.

The problem is that by inspecting a class you never can really say wether a ctor argument or a setter introduces a dep to a component pos is simply a parameter. You may use some heuristics though, because the usage of a type is quite typical. Maybe a container should be configured which types should be handled as params and which as components and an adapter could evaluate this info at dependency resolution, but there will be again cornercases where the heuristic fails.

- Jörg

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

    http://xircles.codehaus.org/manage_email