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

Paul Hammant wrote:

> 
> On Nov 19, 2007, at 7:45 AM, peter royal wrote:
> 
>> On Nov 19, 2007, at 1:19 AM, Jörg Schaible wrote:
>>> Is it really the intend to generate such kind of a "namespace" for
>>> the key?
>>
>> yes
>>
>>> In that case it would be equivalent to:
>>>
>>> mpc.addComponent(Apple.class.getName() + ":one"), new AppleImpl(1));
>>
>> absolutely
> 
> actually, its similar to, but not the same....
> 
>     Type + Annotation-Hint <> TypeName + Annotation-Hint
> 
> ... to those developers who take pride in being anal ;-)

:D

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.

In all cases you need an explicit key for the Pico to get the proper
implementation, it does not matter if it is a BindKey instance or a
namespaced string. And for my example I'd rather used

mpc.addComponent(FruitBasket.class.getName() + ":one"), AppleImpl1.class);

instead, since the namespace is defined by the usage of the Bind annotation
within FruitBasket? ...

Well, thinking about it, it simply depends on the semantics of the Bind
annotation:

1/ use a named instance of the field's type
2/ use a named parameter of the component

Your (Jason's) test case use the first variant.

>>> ... just like to understand the use case before we're going to add
>>> a new handling for special type of keys (apart from Class types).
>>
>> i don't think there's anything new/special required, it was more of
>> an illustration for jason on how it could be done.
>>
>> (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. 

> Yup, I'm going direct to the DI use of the same concepts, trying to
> make a testcase close to Jason's real examples.
> 
> Jason, can you link to a component in your Svn that uses binding
> annotations already ?

Well, the test case can be boiled down to:

    public void testJasonsNeed() {
        MutablePicoContainer mpc = new DefaultPicoContainer();
        mpc.addComponent(FruitBasket.class);
        FruitBasket fb = mpc.getComponent(FruitBasket.class);
//        assertEquals(fb.one.getX(), 1);
//        assertEquals(fb.two.getX(), 2);
//        assertEquals(fb.three.getX(), 3);
//        assertEquals(fb.four.getX(), 4);
    }

    public static class FruitBasket {
        private @Bind(id = AppleImpl1.class) Apple one;
        private @Bind(id = AppleImpl2.class) Apple two;
        private @Bind(id = AppleImpl3.class) Apple three;
        private @Bind(id = AppleImpl4.class) Apple four;
    }

    public static class AppleImpl1 implements Apple {
        public int getX() {
            return 1;
        }
    }

    ...


or a bit more flexible:

    public void testJasonsNeed() {
        MutablePicoContainer mpc = new DefaultPicoContainer();
        mpc.addComponent(FruitBasket.class);
        FruitBasket fb = mpc.getComponent(FruitBasket.class);
//        assertEquals(fb.one.getX(), 1);
//        assertEquals(fb.two.getX(), 2);
//        assertEquals(fb.three.getX(), 3);
//        assertEquals(fb.four.getX(), 4);
    }

    public static class FruitBasket {
        private @Bind(id = "one") Apple one;
        private @Bind(id = "two") Apple two;
        private @Bind(id = "three") Apple three;
        private @Bind(id = "four") Apple four;
    }

    @Key("one")
    public static class AppleImpl1 implements Apple {
        public int getX() {
            return 1;
        }
    }



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?

- Jörg


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

    http://xircles.codehaus.org/manage_email