On Thu, Jan 9, 2014 at 11:32 PM, Igor Vaynberg <[email protected]>wrote:
> On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov <[email protected]> > wrote: > > Hi Igor, > > > > While I see what you mean I think that often this is not the case. At > least > > when using open source library. > > Most of the time users/developers do not read Javadoc but use the code > > directly. > > this is not my experience. most users can barely attach javadoc to > their ide, not even speaking about source. here is where we think differently if the user is not experienced enough this is not a problem of the library/framework/OS (LFOS) (s)he uses if the LFOS stays in the way of the user/developer then the problem is in the LFOS now the question is whether the LFOS should provide a single (the proper) way to do something or it should provide a sane default way and let the user choose a better one for her/his use cases the user may choose a worse way but this is not something the LFOS should prevent on any price more experienced users appreciate the provided flexibility example from yesterday/today: - a user complains that ajax multipart form submit doesn't work for FF - I ask for a quickstart - the user creates a quickstart and realizes that the problem is in his custom code - the user apologies and continues his work I think users complain more when the LFOS doesn't allow them to do something good than when the LFOS doesn't prevent them to do something bad. > > > If I want to override a method I'd first consult with the source of the > > overridden method, not with the Javadoc of the overridden method or its > > super. > > if you consulted with the source you would see that there is no reason > to override that method directly as its functionality can be > completely replaced by overriding postprocess()... so why override the > original? > For example to prevent MissingResourceException that may be thrown if the app doesn't have a value for the resource key. > > -igor > > > > > > Martin Grigorov > > Wicket Training and Consulting > > > > > > On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <[email protected] > >wrote: > > > >> the method is final because overriding it means you will most likely > >> break the contract of the resourceKey and postprocess methods which > >> are meant to be used by you to customze the behavior of > >> getDisplayValue(). > >> > >> so lets say you create subclass MyEnumChoiceRenderer with an > >> overridden getDisplayValue() that no longer calls postprocess(). then > >> someone subclasses your subclass and overrides postprocess() expecting > >> it to be called (thats what the javadoc says) but it wont be, because > >> you broke the contract. > >> > >> having getDisplayValue() be final prevents you from breaking this > >> contract and saving hours of head scratching down the road. > >> > >> if you look at EnumChoiceRenderer without getDisplayValue() there is > >> only one meaningful line of code left: > >> > >> return Classes.simpleName(object.getDeclaringClass()) + '.' + > object.name > >> (); > >> > >> everything else is javadoc or declarations. so why all the fuss over a > >> trivial line of code? > >> > >> -igor > >> > >> ps: ironically if you did want to override getDisplayValue() in a way > >> that broke the contract you would have to make your subclass final so > >> no one further down the road could subclass it... > >> > >> > >> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer < > [email protected]> > >> wrote: > >> > Hi, > >> > > >> > I just tried to customize EnumChoiceRenderer and to override > >> > getDisplayValue, but is final. Why? > >> > > >> > Can I submit a patch to remove final? > >> > > >> > Bye, > >> > > >> > Oliver > >> > > >> > --------------------------------------------------------------------- > >> > 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] > >
