www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Subclassing "Not inteded for subclassing"

reply 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?
Oct 14 2008
parent reply 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?
Oct 14 2008
next sibling parent reply 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)
Oct 15 2008
parent 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
Oct 15 2008
prev sibling parent reply 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.
Oct 15 2008
parent 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.

Oct 15 2008