• Simen Haugen (8/8) Oct 14 2008 I see dwt also have the "Not intended for subclassing", but the classes
• Frank Benoit (16/26) Oct 14 2008 Hehe, i don't know why, but i simply forgot about making them 'final'.
• Aarti_pl (19/50) Oct 15 2008 Frank, please do not make them final! :-O
• Frank Benoit (2/59) Oct 15 2008 ok, i see
• Jacob Carlborg (3/5) Oct 15 2008 Frank you can't break the API by setting a class final that isn't final
• Frank Benoit (2/9) Oct 15 2008 right

Simen Haugen <simen norstat.no> writes:

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?

Frank Benoit <keinfarbton googlemail.com> writes:

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?

Aarti_pl <aarti interia.pl> writes:

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 <keinfarbton googlemail.com> writes:

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 <doobnet gmail.com> writes:

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.

Frank Benoit <keinfarbton googlemail.com> writes:

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