Re: Making Component easier to Generify

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