[weld-dev] Decorator question

Gavin King gavin.king at gmail.com
Fri Dec 4 23:21:47 EST 2009


Oh, now I understand. Yes, Cat/CatDecorator look wrong to me. Cat
should be an interface, with a CatImpl.

On Fri, Dec 4, 2009 at 8:42 PM, Gavin King <gavin.king at gmail.com> wrote:
> Then I guess I don't understand exactly what it is that you want here...
>
> On Fri, Dec 4, 2009 at 6:20 PM, Mark Struberg <struberg at yahoo.de> wrote:
>> Gavin,
>>
>> my main concern is to pass the TCK.
>>
>> Beside that, I really don't like to propose new use cases (even if there is one: with @Alternative, you'd need to subclass every class down the type hierarchy yourself, with @Decorator 'extends', you'd be able to decorate the baseclass and that would be applied to all subclasses automagically).
>>
>> Maybe the TCK folks can look at the CatDecorator, and add a bit more Decorator tests, so we have a set of facts we can both rely on? txs!
>>
>> LieGrue,
>> strub
>>
>> --- Gavin King <gavin.king at gmail.com> schrieb am Fr, 4.12.2009:
>>
>>> Von: Gavin King <gavin.king at gmail.com>
>>> Betreff: Re: [weld-dev] Decorator question
>>> An: "Mark Struberg" <struberg at yahoo.de>
>>> CC: "Marius Bogoevici" <mariusb at redhat.com>, weld-dev at lists.jboss.org
>>> Datum: Freitag, 4. Dezember 2009, 17:51
>>> Look, I just don't see the usecase
>>> for what you're proposing.
>>>
>>> If you're trying to extend a concrete class, override some
>>> of its
>>> methods, and delegate some methods back to the superclass,
>>> just make
>>> your subclass an @Alternative and call super.
>>>
>>> I simply don't see the usecase for having a whole stack of
>>> these
>>> things. I don't think anyone needs this.
>>>
>>> On Fri, Dec 4, 2009 at 2:21 AM, Mark Struberg <struberg at yahoo.de>
>>> wrote:
>>> > But if (2) is allowed, then the restriction on the
>>> Interfaces is pretty restrictive. I cannot see any
>>> additional benefit we gain from this restriction and we have
>>> to delegate all not-overridden methods via a proxy anyway.
>>> > Can you please give me a hint why this is necessary?
>>> >
>>> > txs and lieGrue,
>>> > strub
>>> >
>>> >
>>> > --- Gavin King <gavin.king at gmail.com>
>>> schrieb am Fr, 4.12.2009:
>>> >
>>> >> Von: Gavin King <gavin.king at gmail.com>
>>> >> Betreff: Re: [weld-dev] Decorator question
>>> >> An: "Marius Bogoevici" <mariusb at redhat.com>
>>> >> CC: "Mark Struberg" <struberg at yahoo.de>,
>>> weld-dev at lists.jboss.org
>>> >> Datum: Freitag, 4. Dezember 2009, 1:56
>>> >> On Thu, Dec 3, 2009 at 6:44 PM,
>>> >> Marius Bogoevici <mariusb at redhat.com>
>>> >> wrote:
>>> >>
>>> >> > a) You can still have (2), if
>>> AnotherBeanClass
>>> >> implements an interface
>>> >> > AnInterface. It's just that the set of
>>> decorated
>>> >> methods is restricted to
>>> >> > the ones defined in the interface.
>>> >>
>>> >> Actually, yes, that's true. I should have said
>>> that.
>>> >
>>> > __________________________________________________
>>> > Do You Yahoo!?
>>> > Sie sind Spam leid? Yahoo! Mail verfügt über einen
>>> herausragenden Schutz gegen Massenmails.
>>> > http://mail.yahoo.com
>>> >
>>>
>>>
>>>
>>> --
>>> Gavin King
>>> gavin.king at gmail.com
>>> http://in.relation.to/Bloggers/Gavin
>>> http://hibernate.org
>>> http://seamframework.org
>>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
>> http://mail.yahoo.com
>>
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



More information about the weld-dev mailing list