[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-swt-dev] Re: Subclassing Shell
- From: "Christian Gruber" <cgruber@xxxxxxxxxxx>
- Date: Thu, 8 Jan 2004 22:46:11 -0500
- Delivered-to: firstname.lastname@example.org
Cool. Thanks for the clarification.
----- Original Message -----
From: "Bob Foster" <bob@xxxxxxxxxx>
Sent: Thursday, January 08, 2004 10:31 PM
Subject: 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
> > done with it? Not a criticism, just curious about the rationale. I can
> > 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).
> > however, really is exclusive to sub-classes, so I'm curious what the
> > is, or the detriment to simply hiding them further. Evolution
> > 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
> > 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.
> >>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
> >>Classes like this should be subclassed only to fix urgent bugs there is
> >>no other way to fix.
> >>Bob Foster
> >>platform-swt-dev mailing list
> > _______________________________________________
> > platform-swt-dev mailing list
> > platform-swt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
> platform-swt-dev mailing list