right. so when you would do it with a class you will actually have to rewire all the methods to forward to the delegate instead of calling super. that is pure insanity and does not make any sense when methods hold logic. that is why it works with an interface, no logic for you to override and forward to the delegate, only the message dispatch itself. sure, technically you can do it even with a concrete class, but you can also do a lot of other things that dont make sense.
-igor On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: > Igor Vaynberg wrote: >> >> look at the java example. notice Window is an interface. >> > > Yeah, but that's just because it's good practice to use the interface when > there is one. Notice that the actually decorated class is a new > SimpleWindow() in DecoratedWindowTest. Window might as well have been an > abstract class, or even a concrete one. The idea is that the contract of the > class you wrap is maintained, if that is an interface your decorator > implements that, when it's a class your decorator extends it. Same idea. Of > course, interfaces are cleaner and you can even decorate more then one > interface when you want to, but decorating a class is not uncommon practice > (at least where I come from). > > Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html > >> eg you cant do: add(new DecoratedComponent(someOtherComponent)); >> > > No, because component has final methods that you can't override so you can't > delegate to them (that whas my point), but not because you can't decorate a > class. > > Matthijs. > > PS. If you insist on that you can only decorate an interface, I'll call it > wrap-extend or something :) > >> -igor >> >> On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Why would the decorator design pattern only work with interfaces? Maybe >>> we're talking about two different this here? (I'm talking about this one: >>> http://en.wikipedia.org/wiki/Decorator_pattern) >>> >>> I can see why behaviors were introduced. A simple example: a factory >>> method >>> creates a link. In my subclass I want the same link with the same onClick >>> behavior but I also want "hello" to be outputted to System.out. How would >>> I >>> go about doing this with a Behavior? I couldn't figure it out... (which >>> isn't saying it's impossible). >>> >>> Matthijs >>> >>> [EMAIL PROTECTED] wrote: >>> >>>> >>>> decorators only work with interfaces, component class is not. This is >>>> part of the reason why we have behaviors >>>> >>>> -igor >>>> >>>> On 6/12/08, Matthijs Wensveen <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> >>>>> Some useful design patterns like Decorator don't work with final >>>>> methods. Wicket components sometimes have overridable factory methods >>>>> for child components. The decorator pattern could be very useful here, >>>>> because you'd be able to decorate the original component with some >>>>> extra >>>>> functionality (Link.onClick for example). Unfortunately this doesn't >>>>> work because some methods are final. >>>>> >>>>> Matthijs >>>>> >>>>> Igor Vaynberg wrote: >>>>> >>>>> >>>>>> >>>>>> i mean generally, for methods, fields, and func args :) most of this >>>>>> stuff can stay final, but people dont bother doing it because its >>>>>> extra typing. >>>>>> >>>>>> -igor >>>>>> >>>>>> On Thu, Jun 12, 2008 at 8:38 AM, James Carman >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> You mean like C++? >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>> <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>> >>>>>>>> -igor >>>>>>>> >>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>> <[EMAIL PROTECTED]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Without the use of final wicket would not have made it this far. >>>>>>>>> >>>>>>>>> Martijn >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <[EMAIL PROTECTED]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I understand the reasoning, however I think "best practice" can be >>>>>>>>>> debated. >>>>>>>>>> To use your example Swing allows the user to override quite a bit, >>>>>>>>>> and >>>>>>>>>> it >>>>>>>>>> doesn't make any (or very few) assumptions on what should and >>>>>>>>>> should >>>>>>>>>> not be >>>>>>>>>> done. >>>>>>>>>> >>>>>>>>>> I don't like API's that assume I'm an idiot and prevent me from >>>>>>>>>> manipulating >>>>>>>>>> them how I see fit. If I cause a bug that I have to deal with, >>>>>>>>>> thats >>>>>>>>>> *my* >>>>>>>>>> problem to resolve. >>>>>>>>>> >>>>>>>>>> In my book (and I'm not the only one) excessive use of final is an >>>>>>>>>> anti-pattern. >>>>>>>>>> >>>>>>>>>> - Brill Pappin >>>>>>>>>> >>>>>>>>>> On 12-Jun-08, at 10:01 AM, cowwoc wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Brill, >>>>>>>>>>> >>>>>>>>>>> This is actually an API "best practice". Classes fall into two >>>>>>>>>>> categories: >>>>>>>>>>> ones designed for subclassing, and ones designed to be final. The >>>>>>>>>>> same >>>>>>>>>>> goes >>>>>>>>>>> for methods. Swing is full of examples of what goes wrong when >>>>>>>>>>> people >>>>>>>>>>> override methods in classes that haven't been designed with >>>>>>>>>>> subclassing in >>>>>>>>>>> mind. >>>>>>>>>>> >>>>>>>>>>> Gili >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Brill Pappin wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> on removing the finals >>>>>>>>>>>> >>>>>>>>>>>> The final members are the worst thing I've had to deal with in >>>>>>>>>>>> Wicket >>>>>>>>>>>> so far. >>>>>>>>>>>> Although I understand that there may be a reason for them, they >>>>>>>>>>>> are >>>>>>>>>>>> more a hinderance than anything else and seem to be trying to >>>>>>>>>>>> "protect >>>>>>>>>>>> users from themselves". >>>>>>>>>>>> >>>>>>>>>>>> - Brill Pappin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Have you considered moving from subclassing to composition in >>>>>>>>>>>>> Wicket >>>>>>>>>>>>> using >>>>>>>>>>>>> Callable<T>? >>>>>>>>>>>>> >>>>>>>>>>>>> Currently it is quite common for developers to subclass a >>>>>>>>>>>>> component >>>>>>>>>>>>> in order >>>>>>>>>>>>> to override isVisible() and other properties. I am proposing >>>>>>>>>>>>> that >>>>>>>>>>>>> instead >>>>>>>>>>>>> the component classes become final and properties may only be >>>>>>>>>>>>> set >>>>>>>>>>>>> using >>>>>>>>>>>>> setter methods. The setter methods would take Callable<T> >>>>>>>>>>>>> instead >>>>>>>>>>>>> of >>>>>>>>>>>>> T, so >>>>>>>>>>>>> for example setVisible(boolean) would become >>>>>>>>>>>>> setVisible(Callable<Boolean>) >>>>>>>>>>>>> >>>>>>>>>>>>> The benefit of this approach is that you could introduce static >>>>>>>>>>>>> factory >>>>>>>>>>>>> methods to the Wicket components which would make them much >>>>>>>>>>>>> easier >>>>>>>>>>>>> to use in >>>>>>>>>>>>> their Generic form. You could then introduce various helper >>>>>>>>>>>>> classes >>>>>>>>>>>>> to >>>>>>>>>>>>> create Callable<T> for constant values, such as >>>>>>>>>>>>> Callable.valueOf(true) would >>>>>>>>>>>>> return a Callable<Boolean> that always returns true. >>>>>>>>>>>>> -- >>>>>>>>>>>>> View this message in context: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html >>>>>>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> View this message in context: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html >>>>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Become a Wicket expert, learn from the best: >>>>>>>>> http://wicketinaction.com >>>>>>>>> Apache Wicket 1.3.3 is released >>>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
