On Wed, 16 February 2000, "Norton, Chris" wrote:

> 
> Hi Yoshiki & friends.
> 
> On Feb. 16, 2000 2:21 PM, Yoshiki Ohshima [ohshima at is.titech.ac.jp] wrote:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <snip> "When I was writing #addCustomMenuItems:hand: for a morph, I wish I
> could write something like
> 
>    super super addCustomMenuItems: aCustomMenu hand: aHandMorph.
> 
> at the top of the method.  The intention was to bypass the superclass'
> #addCustomMenuItems but want to call the supersuperclass' one before adding
> my own menu items."  <snip>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I have to admit that I've always wanted a super super construct.  I have had
> several (admittedly poorly factored) cases where I wanted to get back to the
> original implementation of a method (Object>>something) and I was stuck
> cutting & pasting the code into my subclass.

[snip]

Hmmm....  Let's think about this.  A>>foo, B inherits from A, C inherits from B.
So, what are the possibilities?  If B doesn't have a foo, as B>>foo, then A>>foo 
is already visible to C, as C inherits from B.  If B _does_ have a foo, then 
there's  

       A>>foo
         |
       B>>foo
         |
       C>>foo  ??

Looks to me -- and I know you said the thing wasn't refactored -- 
like C ought to inherit from A, not B.



______________________________________________________
Jan Theodore Galkowski      www.smalltalk.org/ 
    http://www.scguild.com/usr/1707I.html 
demiourgos at smalltalk.org  www.marssociety.org/
**********************************************
PGP Key Fingerprint: 2757 F86D AA51 677D 38D7  
                     964B 9A8D 7852 A494 3790
**********************************************
Get my Public Key from my home page at:
    http://algebraist.com/
**********************************************

______________________________________________

Get free e-mail at http://www.britannica.com