Home > Archive > Smalltalk > March 2005 > Explanation of "super" (why infinite loop?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Explanation of "super" (why infinite loop?)
|
|
|
| I have a question to Alex Sharps book "Smalltalk by Example".
In chapter 2 "Messages" Alex tries to explain the Smalltalk
feature "super".
He says "super" refers to the class object rather that the
object inherited from. That's the same in C++ which I am familiar
with.
What I don't understand is his explanation. Alex says otherwise
processing a message would end up in an infinite loop! Why???
Thanks for helping out a Smalltalk rookie.
| |
| Arie van Wingerden 2005-02-12, 3:58 pm |
| Hi,
you might have a look at
file:///D:/webcontent/www.iam.unibe.ch/~ducasse/FreeBooks/ByExample/04%20-%20Chapter%202%20-%20Messages.pdf
Especially where it says:
In fact, super does not refer to the superclass of the object that
received the message. Instead, it refers to the superclass of the object
that defined the code of the method being executed.
B.t.w., this is part of the collection free books to be found at:
file:///D:/webcontent/www.iam.unibe.ch/~ducasse/FreeBooks.html
--
Met vriendelijke groet / with kind regards,
Arie van Wingerden
"The best way to predict the future is to invent it."
# Alan Kay #
"vl106" <vl106@hotmail.com> schreef in bericht
news:420e3dfc_2@news.arcor-ip.de...
> I have a question to Alex Sharps book "Smalltalk by Example".
>
> In chapter 2 "Messages" Alex tries to explain the Smalltalk
> feature "super".
>
> He says "super" refers to the class object rather that the
> object inherited from. That's the same in C++ which I am familiar
> with.
>
> What I don't understand is his explanation. Alex says otherwise
> processing a message would end up in an infinite loop! Why???
>
> Thanks for helping out a Smalltalk rookie.
>
>
| |
| Peter van Rooijen 2005-02-12, 8:58 pm |
| Arie van Wingerden wrote:
> Hi,
>
> you might have a look at
> file:///D:/webcontent/www.iam.unibe.ch/~ducasse/FreeBooks/ByExample/04%20-%20Chapter%202%20-%20Messages.pdf
> Especially where it says:
> In fact, super does not refer to the superclass of the object that
> received the message. Instead, it refers to the superclass of the object
> that defined the code of the method being executed.
Well, depending on what "refers to" means, that's not quite accurate.
super refers to the exact same object that self does.
So, if you send a message to super, it is sent to the same object it
would be sent to if the message was sent to self.
The only difference is that when the appropriate method to be executed
is looked up, any matching method in the class in which the method with
super is defined, or any of its subclasses, down to the class of the
receiver, will not be used (as would be the case if the message was sent
to self).
Instead, the method defined in the closest superclass of teh class in
which the message with super is defined, will be used.
This is very useful when you want to define a method #foo, and as part
of the body, you want the inherited method #foo to be called on the
receiver. If you simply sent self foo, you could end up in an endless
recursion (which the VM might or might not - depending on the
implementation - detect, and if it doesn't your image would hang).
You will often see messages to super used to chain method with the same
name along a hierarchy, such as is typically useful for initialization.
But you are not restricted to sending the same message to super as is
currently executing. There are good reasons for doing such a thing, but
usually, you don't want to do this.
Since every method is defined in exactly one class, the superclass is
known when a method is defined, and the compiler may actually store a
reference to exactly that class in the compiled method. In that sense,
super could be said to refer to the superclass of the class in which the
method is defined. But the object that receives the message is not the
superclass, rather it is the same object that self refers to.
Note that while it is not generally an error to send a message to an
object that does not have a method with the same selector as the
message, it *is* an error to send a message to super when there is no
method with the same selector as the message. Depending on the
implementation, the program may exit, or you may still get into a
doesNotUnderstand:, with a chance to continue processing, just as if the
message was sent to self and there was no matching method.
So, in a method defined in the class Object (which has no superclass),
sending a super message is always an error.
Hope this helps clarify the situation,
Peter
> B.t.w., this is part of the collection free books to be found at:
> file:///D:/webcontent/www.iam.unibe.ch/~ducasse/FreeBooks.html
>
| |
|
| Peter van Rooijen wrote:
> Hope this helps clarify the situation,
I think your message bears evidence to the fact that
'super' is not one of the simplest concepts in Smalltalk.
I steer away from 'super' whenever I can. It makes your
code shorter, which is good, but it also makes it harder
to maintain in the long run.
The main problem with 'super' is that it introduces
(more) coupling (than necessary) between my class and
an /unspecified/ superclass!
As an alternative to using 'super' I typically create
a new method in the superclass called #myMethodSUPER
or something, and call it explicitly, when I need its
behavior.
-Panu Viljamaa
| |
| Jaroslaw Podgajny 2005-02-27, 4:01 pm |
| panu wrote:
[snip]
> I steer away from 'super' whenever I can. It makes your
> code shorter, which is good, but it also makes it harder
> to maintain in the long run.
>
> The main problem with 'super' is that it introduces
> (more) coupling (than necessary) between my class and
> an /unspecified/ superclass!
Is it my news reader not picking up message ids properly or really
nobody chellanged this statement?! Or have I misunderstood it?
'super' is the basic mechanism to specialize behaviour within
inheritance tree. And inheritance sure does cause coupling but that is
actually desired effect while specializing from a superclass.
> As an alternative to using 'super' I typically create
> a new method in the superclass called #myMethodSUPER
> or something, and call it explicitly, when I need its
> behavior.
The only time I have seen that approach used was when bypassing
undesired super implementation, e.g. imagine inheriting from
OrderedCollection and avoiding super implementation of #size - in that
case one would define
size
^self basicSize.
And even in such a case it is a sign of a compromised design.
Regards, Jaroslaw.
| |
|
| Jaroslaw Podgajny wrote:
> The only time I have seen that approach used was when bypassing
> undesired super implementation, e.g. imagine inheriting from
> OrderedCollection and avoiding super implementation of #size - in that
> case one would define
>
> size
> ^self basicSize.
>
> And even in such a case it is a sign of a compromised design.
Can you explain further, what makes it "compromised design" ?
Thanks
Panu Viljamaa
| |
| Jaroslaw Podgajny 2005-03-19, 8:57 pm |
| panu wrote:
> Jaroslaw Podgajny wrote:
>
>
>
> Can you explain further, what makes it "compromised design" ?
If you find yourself invalidating inherited behaviour it shows that
either constraints in the superclass are too strong or you should not be
inheriting from it.
But that is a very idealistic point of view. In reality "the right
balance" is enough and one surrenders purity of the design in order to
get better utilization of a framework.
Regards, Jaroslaw.
|
|
|
|
|