Re: [platform-swt-dev] Re: Subclassing Shell

["Christian Gruber" <cgruber@xxxxxxxxxxx>]

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?

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
>
>