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]
