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

Hi Konstantin,

Konstantin Priblouda wrote on Saturday, September 15, 2007 5:45 PM:

> --- Jörg Schaible <[email protected]>
> wrote:
> 
> 
>> 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.
> 
> ... and add another complexity level - deployment team
> which likes those parameters  configurable externally.
> ( maybe you got more luck with yours, mine are like
> this ;) )
> 
> In this case value  can not be confgured  in scripts
> inside webapp - it has to be pulled from some external
> configuration ( typically property file available
> n classpath of app server )

Hehehe ... same here. We use a commons-configurations approach.

>> 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.
> 
> formal parameter names  are dangerous - thy are mostly
> short,  and frequently reused in different classes -
> so there is a big probability of collision.
> 
> and you can not always control formal parameter names -
> so this feature looks for me not very usefull.

But this what I tried to explain. The names have local scope to the component. With an own Parameter implemenation you're able to retrieve them from everywhere. In case of CC you can simply use a subtree of the global configuration.

>> 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.
> 
> Is there a real difference?  Component has a
> dependency
> and it is not his business to decide where it comes
> from. This decision is taken when container is
> configured. I think there is no need for heuristics at
> all - when I configure component, I can say "take this
> config parameter" or "take component with this key"

But this was the neat part with the named parameters. See, if a component has 5 deps where 3 of them are in reality config params (e.g. username, password and URL) is would be quite nice to define simply those three as named parameters with local scope (i.e. no other component can see them) and the other two are auto-detected services - name is not important here at all.
 
> Of course, I would be more happy to not to specify
> this explicitely - but you current architecture (where
> parameter object hunts for dependency and knows which
> type is required) dictates that conversion shall
> happen there.

That was one proposal of Thomas once: The Parameter should use the container to resolve the deps, it should not look 'em up itself. And it would be easy - simply provide the container with a list of (possibly named) deps and the container knows, what might fit:

boolean Container.resolveDependencies(Map<Parameter, Object>);

Returns true if the container could assign an object/component to any (named) parameter in the Map.

- Jörg

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

    http://xircles.codehaus.org/manage_email