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]
