[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Re: Subclassing Shell
|
Christian Gruber wrote:
Hi Bob, et. al.
Why would you bother to have protected methods that are subject to
potential API change? Wouldn't you just mark them private or final and be
done with it? Not a criticism, just curious about the rationale. I can see
the need for public but not-guarranteed methods if you need visibility
within a framework, but have sub-divided your packages such that
package-level access is insufficient. (Apple does that a lot). Protected,
however, really is exclusive to sub-classes, so I'm curious what the benefit
is, or the detriment to simply hiding them further. Evolution in-progress
perhaps, or something more deliberate?
"Not designed to be subclassed" doesn't mean that SWT, itself, may not
subclass it. Thus, there are two good reasons for leaving methods
protected: 1) SWT subclasses can override them and 2) the same reason as
not marking the classes final - it may be useful in fixing an urgent bug
to be able to override what the class is doing.
Bob Foster
http://xmlbuddy.com/
regards,
Christian.
----- Original Message -----
From: "Bob Foster" <bob@xxxxxxxxxx>
To: <platform-swt-dev@xxxxxxxxxxx>
Sent: Thursday, January 08, 2004 4:38 PM
Subject: Re: [platform-swt-dev] Re: Subclassing Shell
David Whiteman wrote:
You are definitely well versed in the pros and cons of subclassing vs.
composition.
And these pros and cons do not belong on this list. Whether SWT should
be more "object-oriented" is a permathread and should be directed to the
eclipse-platform newsgroup.
You are *probably* safe if you override an API method to do something
simple, and then call the superclass version of the method. But it
was still not designed to guarantee safe subclassing. The whole thing
is being aware of the risks involved, even if they are small.
With respect, the whole thing is that "not designed to be subclassed"
means that subclassing is not supported. The names or arguments of
protected methods may change in any future release or may the methods
may go away entirely. They may be different on different platforms. Even
if they stay the same, the semantics of the methods and/or the order in
which they are invoked may change. There is no way to assess the risk of
change.
Classes like this should be subclassed only to fix urgent bugs there is
no other way to fix.
Bob Foster
http://xmlbuddy.com/
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
