Hello, everyone.
Welcome to sequence 3.
Now that we have looked at inheritance,
self, and lookup, we'll examine "super."
We'll start by focusing on sending a message
in cases where "super" is the receiver.
What is "super"?
Take a few minutes to think of a definition covering these two points:
What does "super" represent?
How is a method looked up
when a message is sent to "super"?
The following principle
is the same in both Pharo and Java.
The example you see here
is similar to the ones we saw in earlier sequences.
"Super" is used in one method.
Let's think about what happens.
For A new bar,
there's no problem.
It's the same process as before.
The method is run,
and foo returns 10.
In the case of B new bar, let's look at each step.
We send the message "bar"
to the B new object.
The lookup algorithm seeks the method "bar"
starting with the object class.
It finds the method "bar."
It is executed on the receiver.
This "bar" method is the one executed on the receiver.
Now I have to compute "super bar"
and "self foo," and add them together.
We can do "self foo,"
"self foo" sends the message "foo" to the object "self."
"Self" is my B new.
The only "foo" possible is the one in class A.
So "self foo" returns 10.
In "super bar,"
"super" is the receiver.
But the lookup algorithm changes
in the presence of the receiver "super."
It will seek the method "bar"
starting with the super class containing the keyword "super."
"Super" is located in the "bar" method of class B.
We'll be looking for method "bar"
starting in B's superclass, which is A.
So we find this method and that is the one executed.
Foo is sent to self.
"Self" is always the receiving object.
It is B new.
So foo is sent to the initial object.
This is the "foo" that is executed, returning 10.
10 + 10 = 20.
In the case of C new bar,
we note C new, here.
It is an instance of class C. We send it the message "bar."
"Bar" is sought in class C new.
Not found. The class above is searched.
It is there, in B.
So the B new bar will be executed.
This bar is the sum of two message-sendings.
We can start with the second.
We send the message "foo" to the object "self."
Self is still my C New, here. I send the message "foo."
The method is found, and 50 is returned.
I put the value 50 there.
Now we need the first part of the sum, "super bar."
I send the message "bar" to "super," always the receiver.
But the lookup algorithm changes.
It looks for "bar" in the superclass for the class containing "super."
That is, "bar" method in class B.
The algorithm starts looking up "bar" in B's superclass, which is A.
Bar is located here.
This "bar" is executed.
"Self" is still C new. Still this one.
Always the receiver.
We send it the message "foo."
The result is 50, and I have 50 here.
50 + 50 = 100.
The next slide
reviews the details of the lookup algorithm process,
for further study.
"Super" always refers to the receiver.
It's exactly like "self,"
or "this" in Java.
Likewise, "super" in Java is like "this," and always refers to the receiver.
However, when a message is sent to "super," the lookup algorithm changes
and begins searching for a method in the superclass
of the class containing the method being executed.
"Self" and "super" are therefore fundamentally different.
"Self" is dynamic, while "super" is static.
I'll explain that further.
When "foo" is sent to "self,"
the developer has no idea which "foo" method will be executed.
It could be the "foo" located in the same class,
or a "foo" in an existing subclass,
or a "foo" in a subclass created by another developer
before the program is run.
When the "bar" method developer writes "self foo,"
he has no idea which "foo" will be executed.
That's a convenient feature.
It means developers can create a new subclass
to change the behavior of class A.
Conversely, "super" is static.
When the developer writes "super foo,"
he knows which "foo" method will be executed
when the program is run.
When he writes "super foo" here, he knows he is referring
to "foo" in superclass A.
Invariably. Super is static.
We know how the program will be compiled.
Unfortunately, certain books
define "super" wrong.
The definitions make no sense.
Here is a definition we found in a book.
It says that "super" looks for the method...
In other words, "super" prompts the lookup algorithm
to search for the method in the superclass of the receiver's class.
The superclass of the receiver's class.
Actually, this is wrong, as proved by the example shown.
If you take aC as the receiver, its class is C.
The receiver's superclass is therefore B.
If I come down here and execute the command "super foo,"
if the definition given by the book applied,
we would send the message "foo"
to "super," and the "foo" method executed
would be the one in the superclass of the receiver's class.
In other words, this one.
It would send "foo" to "super"
over and over again, in an infinite loop.
So the definition is wrong.
In practice, this example functions perfectly.
It's just that this definition is wrong.
Here's what to remember:
"Self" always represents the receiver.
So does "super."
It's the same in Java, with "this" and "super."
However, "super" changes the lookup.
It will start looking for a match
in the superclass
of the class containing the method that contains the keyword "super."
"Self" sends are dynamic.
The developer can use them to extend the behavior of an existing class,
by creating a subclass that redefines the method.