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]
