Pseudovariable super

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Pseudovariable super

Tortolo Garcia
What is the purpose of the Smalltalk pseudovariable "super"?

Thanks,

Tortolo


Reply | Threaded
Open this post in threaded view
|

Re: Pseudovariable super

Frank Sergeant
Tortolo Garcia <tortolo@208.243.164.16> wrote:
 
> What is the purpose of the Smalltalk pseudovariable "super"?

To affect where in the hierarchy of classes a method lookup
will begin.

      MySuperClass>>doSomething
         <do a lot of hard work>
         <or perhaps only a little work>


      MyClass>>doSomehing
          "MyClass inherits from MySuperClass"
          super doSomething.
          <custom additions for this class>

you certainly would not want to write the second method as

      MyClass>>doSomehing
          self doSomething.
          <custom additions for this class>

as it would produce unwanted infinite recursion.

One key to understanding is that both self and super refer
to the *same* object.


-- Frank
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Pseudovariable super

David Simmons
In reply to this post by Tortolo Garcia
"Tortolo Garcia" <tortolo@208.243.164.16> wrote in message
news:3b363ca8$[hidden email]...
>
> What is the purpose of the Smalltalk pseudovariable "super"?

<super> is a special form of message send to <self>.

Its purpose is to send a message <self>; where the search for a
corresponding method implementation begins in the superclass of the
call-site method's behavior (method-dictionary).
--

Assume class <C> that extends a class <B> which extends a class <A> which
extends <Object>.

    Class name: A.
    Class name: B extends: A.
    Class name: C extends: B.

Given a method #bar defined on class <B>.

    method behavior: B [
    bar
        ^super bar
    ].

    eval [
        (C new) bar.
    ].

The "call-site" for sending the message #bar to <super> is located in a
method of class <B>. So the search for a corresponding #bar method
implementation will begin in <B>'s superclass, which is <A>. NOTE: <self>
happens to be an instance of <C>, but that is irrelevant when a <super>
message is issued.

In the above example, you will note that the "eval" method is sending the
message #bar to an instance of <C>. Which, in this example, will bind to the
#bar implementation in <B>.

If we had sent "self bar" instead of "super bar" in the <B> method
implementation, we would have created an infinite loop.

I.e., the B[##::bar] method would have looped calling itself.
--

In the above example, there is no implementation of #bar in <A>, so the
"super bar" message would result in a #forwardInvocation:withArguments:
message (or a direct call into DNU/DNR (#doesNotUnderstand:withArguments:,
#doesNotRespondTo:withArguments:) in some Smalltalk dialects).

Things to ponder:

1) If <A> had an implementation of #bar what would it do? When and how
should the <B> implementation invoke the inherited implementation from <A>?
I.e., what kind of expressions should it perform before the "super bar" and
what kind of expressions should it invoke after?

2) If <C> had an implementation of #bar how would that change things?  When
or how should the <C> implementation invoke the <B> or <A> implementations?
What do the terms "override", "extend", and "refine" bring to mind in
classifying approaches to implementing a <C> implementation of #bar?


--
-- Dave S. [http://www.smallscript.net]

>
> Thanks,
>
> Tortolo