Re: Why is getDisplayValue in getDisplayValue final?
On Fri, Jan 10, 2014 at 9:41 AM, Martin Grigorov mgrigo...@apache.orgwrote: On Thu, Jan 9, 2014 at 11:32 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov mgrigo...@apache.org 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 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
I see your point and I also think that it is very important to ensure
the contract your class or methods relies on.
But in such a case the method where the method must be final a
customization point should be provided to allow us the modify the part
of the method which is independent of the contract.
For example:
@Override
public final Object getDisplayValue(T object)
{
final String value = getDisplayValueRaw(object);
return postprocess(value);
}
getDisplayValueRaw() whould be the customization point and could be
overwritten by a developer without breaking the method contract.
Oliver
Am 09.01.14 00:12, schrieb Igor Vaynberg:
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Am 10.01.14 08:41, schrieb Martin Grigorov: 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 is exactly my use case. Oliver - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
I dont remember exactly, but I guess I did it four or five times. That is not much but know what each of these is a hidden fork of the original implementation. I wish I had written my custom annotation @WicketFork for these classes ;-) Bye, Oliver Am 08.01.14 10:07, schrieb Martin Grigorov: This is true. The good thing is that Wicket is open source and you can copy the class and modify it locally. If you want to remove the copied code later you will contact us and tell us your use case. This way we get some feedback from our users and improve either Wicket code or users' code :) How many times you had to copy code for this reason ? There are no many complains about this in the mailing lists or in Jira. Last few years we don't use 'final' as the in the early development of Wicket. But we cannot just go over the code and remove all finals. Some of them have to be final. But if the user gives us a good reason we will consider it. Martin Grigorov Wicket Training and Consulting On Wed, Jan 8, 2014 at 10:40 AM, Oliver B. Fischer mails...@swe-blog.netwrote: I see the good point in it but in the moment when I needed a different behaviour it is still final. No one will wait for the next release if you have to do it now. Bye, Oliver Am 07.01.14 16:54, schrieb Martin Grigorov: http://wicket.sourceforge.net/faqs.html#why-final - 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
Re: Why is getDisplayValue in getDisplayValue final?
On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov mgrigo...@apache.org 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. 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? -igor Martin Grigorov Wicket Training and Consulting On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
On Thu, Jan 9, 2014 at 11:32 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov mgrigo...@apache.org 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 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
I see the good point in it but in the moment when I needed a different behaviour it is still final. No one will wait for the next release if you have to do it now. Bye, Oliver Am 07.01.14 16:54, schrieb Martin Grigorov: http://wicket.sourceforge.net/faqs.html#why-final this is the explanation of the designers of Wicket I agree with both sides I don't think that there are too many finals in the code usually if you explain why you need to remove the final we either remove it for the next release or explain a better way Sven asked for the reason already Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 5:21 PM, Steve shadders@gmail.com wrote: Have to agree with this. I've come across the 'final' issues many times in wicket and other libraries. It appears from my own experience with Wicket is that classes/methods are marked final if the developer can't think of a reason someone might want to extend it (Martin, I'm not actually referring to RawMarkup here, there's many other cases I've encountered both in wicket-el and completely unrelated coding adventures). IMHO this is an artificial limitation and they should only be marked final if the expected results of that method form part of a contract that could be broken if the behaviour of the implementing method differs from the original. In that case it is the responsibility of the overrider to deal with the implications ultimately but if can be dealt with explaining the contract clearly in the javadoc. That way if a downstream developer mucks it up it's on their own head and the wicket devs don't have to deal with the fallout of buggered up design. Again IMHO there are very few legitimate use cases for marking methods or classes final in an OS library. Closed source I can understand. On 08/01/14 00:53, Oliver B. Fischer wrote: There are to much final methods in Wicket. This leads to copying code instead of overriding only the methods you would like to change. Oliver Am 07.01.14 15:44, schrieb Martin Grigorov: On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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 - 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
Re: Why is getDisplayValue in getDisplayValue final?
This is true. The good thing is that Wicket is open source and you can copy the class and modify it locally. If you want to remove the copied code later you will contact us and tell us your use case. This way we get some feedback from our users and improve either Wicket code or users' code :) How many times you had to copy code for this reason ? There are no many complains about this in the mailing lists or in Jira. Last few years we don't use 'final' as the in the early development of Wicket. But we cannot just go over the code and remove all finals. Some of them have to be final. But if the user gives us a good reason we will consider it. Martin Grigorov Wicket Training and Consulting On Wed, Jan 8, 2014 at 10:40 AM, Oliver B. Fischer mails...@swe-blog.netwrote: I see the good point in it but in the moment when I needed a different behaviour it is still final. No one will wait for the next release if you have to do it now. Bye, Oliver Am 07.01.14 16:54, schrieb Martin Grigorov: http://wicket.sourceforge.net/faqs.html#why-final this is the explanation of the designers of Wicket I agree with both sides I don't think that there are too many finals in the code usually if you explain why you need to remove the final we either remove it for the next release or explain a better way Sven asked for the reason already Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 5:21 PM, Steve shadders@gmail.com wrote: Have to agree with this. I've come across the 'final' issues many times in wicket and other libraries. It appears from my own experience with Wicket is that classes/methods are marked final if the developer can't think of a reason someone might want to extend it (Martin, I'm not actually referring to RawMarkup here, there's many other cases I've encountered both in wicket-el and completely unrelated coding adventures). IMHO this is an artificial limitation and they should only be marked final if the expected results of that method form part of a contract that could be broken if the behaviour of the implementing method differs from the original. In that case it is the responsibility of the overrider to deal with the implications ultimately but if can be dealt with explaining the contract clearly in the javadoc. That way if a downstream developer mucks it up it's on their own head and the wicket devs don't have to deal with the fallout of buggered up design. Again IMHO there are very few legitimate use cases for marking methods or classes final in an OS library. Closed source I can understand. On 08/01/14 00:53, Oliver B. Fischer wrote: There are to much final methods in Wicket. This leads to copying code instead of overriding only the methods you would like to change. Oliver Am 07.01.14 15:44, schrieb Martin Grigorov: On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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 - 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
Re: Why is getDisplayValue in getDisplayValue final?
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
Re: Why is getDisplayValue in getDisplayValue final?
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.comwrote: 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
Why is getDisplayValue in getDisplayValue final?
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
Re: Why is getDisplayValue in getDisplayValue final?
You have #resourceKey() and #postprocess() to override - what do you need more? Sven On 01/07/2014 03:37 PM, Oliver B. Fischer 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
Re: Why is getDisplayValue in getDisplayValue final?
Hi, It is no more final in 7.x. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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
Re: Why is getDisplayValue in getDisplayValue final?
On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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
Re: Why is getDisplayValue in getDisplayValue final?
There are to much final methods in Wicket. This leads to copying code instead of overriding only the methods you would like to change. Oliver Am 07.01.14 15:44, schrieb Martin Grigorov: On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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
Re: Why is getDisplayValue in getDisplayValue final?
Have to agree with this. I've come across the 'final' issues many times in wicket and other libraries. It appears from my own experience with Wicket is that classes/methods are marked final if the developer can't think of a reason someone might want to extend it (Martin, I'm not actually referring to RawMarkup here, there's many other cases I've encountered both in wicket-el and completely unrelated coding adventures). IMHO this is an artificial limitation and they should only be marked final if the expected results of that method form part of a contract that could be broken if the behaviour of the implementing method differs from the original. In that case it is the responsibility of the overrider to deal with the implications ultimately but if can be dealt with explaining the contract clearly in the javadoc. That way if a downstream developer mucks it up it's on their own head and the wicket devs don't have to deal with the fallout of buggered up design. Again IMHO there are very few legitimate use cases for marking methods or classes final in an OS library. Closed source I can understand. On 08/01/14 00:53, Oliver B. Fischer wrote: There are to much final methods in Wicket. This leads to copying code instead of overriding only the methods you would like to change. Oliver Am 07.01.14 15:44, schrieb Martin Grigorov: On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
http://wicket.sourceforge.net/faqs.html#why-final this is the explanation of the designers of Wicket I agree with both sides I don't think that there are too many finals in the code usually if you explain why you need to remove the final we either remove it for the next release or explain a better way Sven asked for the reason already Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 5:21 PM, Steve shadders@gmail.com wrote: Have to agree with this. I've come across the 'final' issues many times in wicket and other libraries. It appears from my own experience with Wicket is that classes/methods are marked final if the developer can't think of a reason someone might want to extend it (Martin, I'm not actually referring to RawMarkup here, there's many other cases I've encountered both in wicket-el and completely unrelated coding adventures). IMHO this is an artificial limitation and they should only be marked final if the expected results of that method form part of a contract that could be broken if the behaviour of the implementing method differs from the original. In that case it is the responsibility of the overrider to deal with the implications ultimately but if can be dealt with explaining the contract clearly in the javadoc. That way if a downstream developer mucks it up it's on their own head and the wicket devs don't have to deal with the fallout of buggered up design. Again IMHO there are very few legitimate use cases for marking methods or classes final in an OS library. Closed source I can understand. On 08/01/14 00:53, Oliver B. Fischer wrote: There are to much final methods in Wicket. This leads to copying code instead of overriding only the methods you would like to change. Oliver Am 07.01.14 15:44, schrieb Martin Grigorov: On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, It is no more final in 7.x. Actually it is still final. I have been confused with another method. I don't mind removing final in 6.x too. Martin Grigorov Wicket Training and Consulting On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer mails...@swe-blog.netwrote: 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
