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

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


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


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

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. 

regards,

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


      ____________________________________________________________________________________
Tonight's top picks. What will you watch tonight? Preview the hottest shows on Yahoo! TV.
http://tv.yahoo.com/ 


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

    http://xircles.codehaus.org/manage_email