Restricting super calls to inherited method

Jecel Assumpcao Jr jecel at merlintec.com
Sun May 20 21:33:46 UTC 2001


On Saturday 19 May 2001 12:47, Paul Fernhout wrote:
> Jecel, I'd love to hear your comments!

You rang, sir?

First of all, if you look at the dynamic execution frequency of the 
"super" bytecode (where is my Green Book when I need it?) you will note 
that there isn't anything you can do there that will affect overall 
performance.

And I don't see how you could have an optimization system that would 
transform an "inherited" bytecode into a jump but wouldn't be able to 
just as easily do the same for "super foo" (in a non #foo method). It 
seems to me that you would have all of the same complexities, specially 
having to keep track of any changes to superclasses that might cause 
you to recompile the method with this optimization.

Self is even worse than Squeak in that it has two bytecodes to handle 
"super" and an ugly syntax to go with it:

                resend.foo

is exactly like "super foo" in Smalltalk, while

                circuitParent.foo

will only look in the "circuitParent" side of the multiple inheritance 
chain for "foo". If you have only one parent then the two are 
equivalent, of course. This is one of the only two uses of named 
parents (the other is dynamic inheritance). Alan Kay has pointed out 
that this mixes base and meta level programming. Of course, named 
classes as in C++ or Java (Circuit::foo()) are no better. It might be 
the case that mixing levels is unavoidable when you need things like 
"super" or "inner".

Performance is not a problem in Self since it can inline away all 
message sends when the receiver is a known type. With "customized 
compilation" self is always a known type, as is super. Inlining is much 
better than a direct call or jump since you can get rid of nearly all 
of the overhead of such a dynamic system. The lesson is: design the 
language to best express what you want to say and let the implementors 
worry about making it fast.

For Self, I would prefer a more general delegation expression instead 
of the above two constructs. It wouldn't quite replace the "resend" for 
the case where I have multiple parents and don't know which one has the 
method I am overriding, but I don't think that will ever be a problem 
in practice.

BTW, I am designing a very simple "kernel" protype based language on 
top of which systems compatible with Self or Squeak can be built. This 
is still in the background mode while I finish another project but we 
should swap ideas.

-- Jecel





More information about the Squeak-dev mailing list