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

Paul, did you had a look?

Basically this stuff could be integrated into the AnnotatedFieldInjector ...

- Jörg

Jörg Schaible wrote:

> 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



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

    http://xircles.codehaus.org/manage_email