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

Hi Paul,

Paul Hammant wrote:

> Nice try guys.
> 
> I've updated the testcase to even more clearly show Jason's need :-
> 
>     http://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/
> container/src/test/org/picocontainer/adapters/JasonsTestCase.java
> 
> He wants to use addComponent(key, impl), not addComponent(key, impl,
> ComponentParameter, ComponentParameter, ComponentParameter,
> ComponentParameter)
> 
> more inline ...

well, nobody talked about that cruft ;-)

>> 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.
>>
> 
> Yes, I'm imagining the BindKey is used internally in DPC /
> ComponentAdapters for matching purposes.
> 
>> 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.
> 
> 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;
        }
    }

In this case the @Key defines the key that is used to register the component
in the AAMPC (I feel even more Guicy ;-).

Since most of us are not very fond of annotations, because of their invasive
nature, it might still be the way to go for a "complete" annotation
support ... and if it is what Jason has in mind. I still don't know how he
wants to set up the relation between the different Apple impls and the id
he defines in @Bind.

Pseudo impl of:

AAMPC.addComponent(Class<?> type) {
        Annotation keyAnn = type.getAnnotation(@Key);
        Parameter[] parameter = getBindings(type);
        if (keyAnn != null) {
            String key = keyAnn.getId() + '/' + keyAnn.getType().getName();
            super.addComponent(key, type, parameter);
        } else {
            super.addComponent(type, type, parameter);
        }
}

- Jörg


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

    http://xircles.codehaus.org/manage_email