It is not about assuming anyone is an idiot. It is about preserving maintainability and allowing an API to evolve without breaking client code. The best approach is to mark members as final unless there is a compelling reason not to. Final is a safeguard for APIs to know what behavior is guaranteed to persist as development and evolution of the API is carried out. Occasionally a user can come up with a good argument for removing the final restriction and makes their case, affecting a change.
It is very easy to create an evolutionary dead end for an API by allowing everything to be overridden. So either deprecate and start over or risk breaking client code and have your users hate you for it :) -----Original Message----- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:09 AM To: users@wicket.apache.org Subject: Re: Making Component easier to Generify 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-yo ur-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-yo ur-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] ______________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
