Re: [picocontainer-dev] Config , Properties and API struggle

Dude,

I would have replied before work today, but got stuck into the groovy  
failing test issue, and that consumed all my time. After work I'll  
give complete it .... so there is something there to discuss.

- Paul

On Sep 7, 2007, at 5:56 AM, Konstantin Priblouda wrote:

> Hi all,
>
> Currently we have some limited support for
> configuration entities. And it looks to me not only
> limited, but
> also not so pretty.
>
> Ugliest part of it ( IMHO of course ) is
> MutablePicoContainer.addConfig(String, Object) - as it
> just a wrapper for adding instance adapter and does
> not introduces any new semantics.
>
> There is also some ugliness in "by param
> name"-fallback in dependency resolution ( which by
> chance breaks nano-groovy )- why do we need this at
> all? It usefullnes is quite limited (and I would say
> potentially dangerous and confusing for users -
> try to explain them why it is needed to use certain
> formal  parameter names in constructors )
>
> Anyway I think that reference to [external]
> configuration item shall be always explicit.
> And place them into special parent containers
> (like attributed) is generally good idea, but needs
> some improvement.
>
> Current implementation by Paul supports only
> integers, booleans and strings - which is not very
> generic approach. It would be really cool to support
> more (at least all primitives from java.lang , maybe
> java.io).  Another prolem is, that it registers
> components with certain type ASAP - but it is
> depending component which decides what type his config
> entry is (say, the same property could be needed as
> string or number. or integer / float)
>
> Anyway, current approach with component adapters  /
> parameters would not allow such "miltitype" extraction
> (because adapter has to know early which type it will
> be serving, and has no information from parameter
> which type is being required - adapter is passive part
> in
> hunt for dependencies)
>
> I propose API change so that adapter can be queried,
> whether it would provide certain data type, instead
> generally hardwiring it (well, classical adapters
> will be hardwired anyway)  - this way parameters could
> resolve the same "config" adapter for different
> types. We will also need mechanism to ask such adapter
> for certain type, prompting conversion from string.
>
> comments and ideas are appreciated.
>
> regards,
>
> ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
> JTec quality components: http://www.pribluda.de/projects/
>
>
>
> ______________________________________________________________________ 
> ______________
> Choose the right car based on your needs.  Check out Yahoo! Autos  
> new Car Finder tool.
> http://autos.yahoo.com/carfinder/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>


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

    http://xircles.codehaus.org/manage_email