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.
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.

Martin Grigorov
Wicket Training and Consulting


On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <igor.vaynb...@gmail.com>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 <mails...@swe-blog.net>
> 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: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to