Re: [weld-dev] Decorator question

Von: Gavin King <gavin.king(a)gmail.com&gt; Betreff: Re: [weld-dev] Decorator question An: "Mark Struberg" <struberg(a)yahoo.de&gt; CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)lists.jboss.org Datum: Samstag, 5. Dezember 2009, 5:21 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(a)gmail.com&gt; 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(a)yahoo.de&gt; 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(a)gmail.com&gt; schrieb am Fr, 4.12.2009: >> >>> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> Betreff: Re: [weld-dev] Decorator question >>> An: "Mark Struberg" <struberg(a)yahoo.de&gt; >>> CC: "Marius Bogoevici" <mariusb(a)redhat.com&gt;, weld-dev(a)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(a)yahoo.de&gt; >>> 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(a)gmail.com&gt; >>> schrieb am Fr, 4.12.2009: >>> > >>> >> Von: Gavin King <gavin.king(a)gmail.com&gt; >>> >> Betreff: Re: [weld-dev] Decorator question >>> >> An: "Marius Bogoevici" <mariusb(a)redhat.com&gt; >>> >> CC: "Mark Struberg" <struberg(a)yahoo.de&gt;, >>> weld-dev(a)lists.jboss.org >>> >> Datum: Freitag, 4. Dezember 2009, 1:56 >>> >> On Thu, Dec 3, 2009 at 6:44 PM, >>> >> Marius Bogoevici <mariusb(a)redhat.com&gt; >>> >> 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(a)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(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org