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

Konstantin Priblouda wrote:

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

Yep

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

>>
>> 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).
Of course, one can have a static defaultConverters() method that instantiates the default ctor, but 
I'm not we'd gain much.

> 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

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

I think this issue merit a discussion thread in its own right.
Personally, have no preconceptions but don't have opinions ATM.

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

Again, separate discussion thread.  ATM paranamer support is experimental.
All discussion is welcome.

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

:-)


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

    http://xircles.codehaus.org/manage_email