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

Paul Hammant wrote:

> 
> On Nov 20, 2007, at 9:45 AM, Jörg Schaible wrote:
>>>
>>> No new method signature - can interop with addComnponent(Object,
>>> Class)
>>
>> No method signature, but a new internal handling for that key type,
>> which is
>> still completely unnecessary. Look into the NotQuiteJasonsNeed
>> example.
>> What you really need is an annotation-aware MPC.
>>
>> aampc.addComponent(FruitBasket.class);
>>
>> This call should be enough (BTW: I never knew, why we did not
>> offered it
>> long ago if key == impl). An annotation-aware container would
>> process also
>> the annotations of the  given impl(s). In the example you should
>> not even
>> have to annotate the @Inject. The @Bind is completely enough (it
>> implies
>> @Inject) for the above call to generate the necessary
>> ComponentParameters
>> on its own (why do I feel so Guicy here) with a key
>> of "Field.getType().geName() + ':' + annotation.getValue()". No
>> need for a
>> BindKey instance at all.
>>
>> What's left is the (automated) registration of the different Apple
>> impls
>> with the appropriate key. But this problem is not solved in both
>> versions.
>>
>> In an AAMPC however you might simply call:
>>
>> aampc.addComponent(AppleImpl1.class);
>>
>> if you have it implemented as:
>>
>>     @Key("one", Apple.class) // you might also implicitly use the
>>                              // first declared iface as alternative
>>     public static class AppleImpl1 implements Apple {
>>         public int getX() {
>>             return 1;
>>         }
>>     }
>>
> 
> This example class makes no sense Jörg.

If you talk about the @Key annotation - maybe - I don't like the usage of
annotations anyway ;-)

> The binding annotation is 
> declared at the injection 'site' (field or parameter for ctor or
> injection method).  Its referred to again as you program the container -
> 
>      pico.addComponent(bindKey(Apple.class, "one"),
> AppleImpl1.class); // or ..
>      pico.addComponent(Apple.class,
> AppleImpl1.class).withBindingAnnotation("one") ;  // TODO if people
> prefer it.

However, you still did not provide any valid reason, why we should handle a
third type of keys.

See the MinimalImplOfJasonsTestCase ...
 
>      guice's closuresque Module implementation:
> 
>      public void configure() {
>          bind(Apple.class).annotatedWith("one").to
> (AppleImpl1.class); // except that Guice's annotations are fully
> typed not string based.
>      }
> 
> See the code I committed before work - adding binding annotations for
> field, constructor and single-method injection.
>>
> 
> Interface PicoContainer got new method :-
> 
>      <T> List<ComponentAdapter<T>> getComponentAdapters(Class<T>
> componentType, String bindId);
> 
> interface Parameter had some changed method signatures
> 
> Lastly, even if people approved of my patch to get binding
> annotations working in Pico, we have to decide whether we are going
> to support the utterly type-safe and very verbose binding style of
> Guice :
> 
>      public Foo(@Hello String one, @How String two, @Are String
> three, @You int four)
> 
> Namely you extend a base annotation (which ain't terse) into your own
> types.

<shudder>
Can we deprecate the complete Annotation stuff in JDK 8? :D
<shudder/>

- Jörg


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

    http://xircles.codehaus.org/manage_email