On Fri, Jan 10, 2014 at 9:41 AM, Martin Grigorov <[email protected]>wrote:
> > > > 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. > This reason seems good enough for me to remove 'final' from the signature of #getDisplayValue() and deprecate #postprocess(). https://issues.apache.org/jira/browse/WICKET-5470 > >> >> -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] >> >> >
