On Thu, Jun 12, 2008 at 9:00 AM, Brill Pappin <[EMAIL PROTECTED]> wrote: > That is the most compelling argument I have ever heard (maintainability > going forward). > saying "i like this by default" as most have done is no argument at all :)
i suppose whenever you write any method that is consumed by hundreds of other developers you put a lot of thought and analysis into all the usecases for which those hundreds of developers will override this method. you think of all the corner cases, and all the things that can go wrong. you do all this by default right? no, you dont? then it is much better to make the method final by default, and once you have done all of the above and made sure that it will all work then remove the final. -igor > > However I disagree "best" is final by default... it should be the other way > around, where things are only marked final if there is a good and immediate > reason to do so. > > Although the debate is long and about as convoluted as the debate of > hungarian notation was, personal experience suggests that everything final > causes more problems than it's worth (I consider the Quartz API to be poor > for that reason also). > > However, I am *in no way asking* the developers to reverse the "final" > policy. its working, and working fairly well. I think I may have started a > thread here that is less than productive and unless others feel that there > needs to be a debate on the issue, I'll let it drop. > > - Brill Pappin > > On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote: > >> 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] >> > > > --------------------------------------------------------------------- > 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]
