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

["Christian Gruber" <cgruber@xxxxxxxxxxx>]

Cool.  Thanks for the clarification.

cg.
----- Original Message -----
From: "Bob Foster" <bob@xxxxxxxxxx>
To: <platform-swt-dev@xxxxxxxxxxx>
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
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
> >
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>