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-your-take-on-generics-with-Wicket-tp17589984p17792488.html>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
users-unsubscribe@...
>>> For additional commands, e-mail:
users-help@...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
users-unsubscribe@...
>> For additional commands, e-mail:
users-help@...
>>
>>
>>
>
> --
> View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
users-unsubscribe@...
> For additional commands, e-mail:
users-help@...
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
users-unsubscribe@...
For additional commands, e-mail:
users-help@...