Re: [picocontainer-dev] Jason van Zyl's need for Plexus

Jörg Schaible wrote:

>>     Type + Annotation-Hint <> TypeName + Annotation-Hint
>>
>> ... to those developers who take pride in being anal ;-)
> 
> :D

But it may not be the simplest solution :-)

> but honestly, it still does not make a difference:
> 
> mpc.addComponent(Apple.class.getName() + ":one"), AppleImpl1.class);
> 
>> I'm committed a new version to show that this is not about by-
>> instance use of PicoContainer, its a bout by-impl
>>
>> Utter type-safety is what Jason needs for something the size of
>> Maven, and he's going to be routinely juggling different impls of the
>> same type during each run.

But different impl will traslate to different keys - eg the impl class 
names.

>>> (the plexus model is similar to the old Avalon/Excalibur one where
>>> you depend on either a class type, or a class type + "role hint".
>>> the latter being what paul's trying to illustrate..)
> 
> Yeah, I remember :)
> BTW: Simply replace my colon with the slash and you're there ... hehehe. 

Yep - indeed.

> Note, that I omitted those calls to on purpose:
> 
> mpc.addComponent(bindKey(Apple.class, "one"), AppleImpl1.class);
> 
> they could be done implicit if the relation is "hard wired enough".
> 
> I simply want to understand which part of this association "FruitBasket.one
> ==> 'one' ==> ApplImpl1.class" is hard wired. The usage of the Bind
> annotation implies for me at least "FruitBasket.one ==> 'one'" as hard
> coded, so how is the "'one' ==> ApplImpl1.class" relation defined in
> reality? What do we gain with a BindKey instance as key instead of a
> namespaced String? How would you define a BindKey in Nano scripts?

If one truly wants strong-typedness, as Joerg was pointing out, one can 
still maintain the Object as the param class but interpret the instance 
of BindKey internally.

Alternatively, the BindKey could be avoided by a convention on the 
Object key String representation.

Defining a new method signature seems very little gain for the changes 
to the API it requires.

Cheers



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

    http://xircles.codehaus.org/manage_email