I see dwt also have the "Not intended for subclassing", but the classes are not marked final.
It shouldn't be any problems subclassing as long as you're careful, right?

Right now I want to subclass Text and automatically add a dynamic tooltip. The same type of text box should be used many places in my application. I know I can just bind each time, but is it really dangerous to do this kind of subclassing to save typing?

Or is there a easier way to solve these kind of things?

Simen Haugen schrieb:
> I see dwt also have the "Not intended for subclassing", but the classes
> are not marked final.
> It shouldn't be any problems subclassing as long as you're careful, right?
> 
> Right now I want to subclass Text and automatically add a dynamic tooltip. The same type of text box should be used many places in my application. I know I can just bind each time, but is it really dangerous to do this kind of subclassing to save typing?
> 
> Or is there a easier way to solve these kind of things?

Hehe, i don't know why, but i simply forgot about making them 'final'.
Perhaps i should do that :)
Well, some of them are subclassed within SWT, but they shall not be
subclasses by user code. (Decorations, Scrollable, ..)

I think, they are not intended for subclassing, because of ...
1. So you do not depend on protected/private API and the SWT project is
free in changing it in a future version.
2. So you do not used protected/private API which may be platform
dependent. There are examples of this.
3. So you do not accidentally change any behavior of the widget, which
might be expected from other classes, like layouts or widget containers.

I am convinced, the SWT devs are very good designers and they choose this restriction for good reason.

Perhaps you can do this by composition instead of inheritance. Do you have code examples of what you want to do?

Frank Benoit pisze:
> Simen Haugen schrieb:
>> I see dwt also have the "Not intended for subclassing", but the classes
>> are not marked final.
>> It shouldn't be any problems subclassing as long as you're careful, right?
>>
>> Right now I want to subclass Text and automatically add a dynamic
>> tooltip. The same type of text box should be used many places in my
>> application. I know I can just bind each time, but is it really
>> dangerous to do this kind of subclassing to save typing?
>>
>> Or is there a easier way to solve these kind of things?
> 
> Hehe, i don't know why, but i simply forgot about making them 'final'.
> Perhaps i should do that :)
> Well, some of them are subclassed within SWT, but they shall not be
> subclasses by user code. (Decorations, Scrollable, ..)
> 
> I think, they are not intended for subclassing, because of ...
> 1. So you do not depend on protected/private API and the SWT project is
> free in changing it in a future version.
> 2. So you do not used protected/private API which may be platform
> dependent. There are examples of this.
> 3. So you do not accidentally change any behavior of the widget, which
> might be expected from other classes, like layouts or widget containers.
> 
> I am convinced, the SWT devs are very good designers and they choose
> this restriction for good reason.
> 
> Perhaps you can do this by composition instead of inheritance.
> Do you have code examples of what you want to do?
> 

Frank, please do not make them final! :-O

I use a few subclassed SWT widgets in my code, and have no problem with them.

To subclass widget it is enough to override method checkSubclass() with empty body:
@Override
protected void checkSubclass() {
}

I think that there should be no problem with subclassing as long as you use there only public interface of SWT.

Finally it is sometimes more convenient to keep updating subclassed widget (because of possible SWT api changes), than make them as aggregated composites and redirect all necessary methods from original widget to new widget. That's why I think even SWT doesn't declare them final...

Best Regards
Marcin Kuszczak
(aarti_pl)

Frank Benoit wrote:
> Hehe, i don't know why, but i simply forgot about making them 'final'.
> Perhaps i should do that :)

Frank you can't break the API by setting a class final that isn't final in SWT.

Aarti_pl schrieb:
> Frank Benoit pisze:
>> Simen Haugen schrieb:
>>> I see dwt also have the "Not intended for subclassing", but the classes
>>> are not marked final.
>>> It shouldn't be any problems subclassing as long as you're careful,
>>> right?
>>>
>>> Right now I want to subclass Text and automatically add a dynamic tooltip. The same type of text box should be used many places in my application. I know I can just bind each time, but is it really dangerous to do this kind of subclassing to save typing?
>>>
>>> Or is there a easier way to solve these kind of things?
>>
>> Hehe, i don't know why, but i simply forgot about making them 'final'.
>> Perhaps i should do that :)
>> Well, some of them are subclassed within SWT, but they shall not be
>> subclasses by user code. (Decorations, Scrollable, ..)
>>
>> I think, they are not intended for subclassing, because of ...
>> 1. So you do not depend on protected/private API and the SWT project is
>> free in changing it in a future version.
>> 2. So you do not used protected/private API which may be platform
>> dependent. There are examples of this.
>> 3. So you do not accidentally change any behavior of the widget, which
>> might be expected from other classes, like layouts or widget containers.
>>
>> I am convinced, the SWT devs are very good designers and they choose this restriction for good reason.
>>
>> Perhaps you can do this by composition instead of inheritance. Do you have code examples of what you want to do?
>>
> 
> Frank, please do not make them final! :-O
> 
> I use a few subclassed SWT widgets in my code, and have no problem with them.
> 
> To subclass widget it is enough to override method checkSubclass() with
> empty body:
> @Override
> protected void checkSubclass() {
> }
> 
> I think that there should be no problem with subclassing as long as you use there only public interface of SWT.
> 
> Finally it is sometimes more convenient to keep updating subclassed widget (because of possible SWT api changes), than make them as aggregated composites and redirect all necessary methods from original widget to new widget. That's why I think even SWT doesn't declare them final...
> 
> Best Regards
> Marcin Kuszczak
> (aarti_pl)

ok, i see

Jacob Carlborg schrieb:
> Frank Benoit wrote:
>> Hehe, i don't know why, but i simply forgot about making them 'final'. Perhaps i should do that :)
> 
> Frank you can't break the API by setting a class final that isn't final in SWT.
> 
right