« Return to Thread: users, please give us your opinion: what is your take on generics with Wicket

Re: Making Component easier to Generify

by Brill Pappin :: Rate this Message:

Reply to Author | View in Thread

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

 « Return to Thread: users, please give us your opinion: what is your take on generics with Wicket