Super and Inner — Together at Last!

Super and Inner — Together at Last! by David S. Goldberg, Robert Bruce Findler, and Matthew Flatt, 2004.
In an object-oriented language, a derived class may declare a method with the same signature as a method in the base class. The meaning of the re-declaration depends on the language. Most commonly, the new declaration overrides the base declaration, perhaps completely replacing it, or perhaps using super to invoke the old implementation. Another possibility is that the base class always controls the method implementation, and the new declaration merely augments the method in the case that the base method calls inner. Each possibility has advantages and disadvantages. In this paper, we explain why programmers need both kinds of method redeclaration, and we present a language that integrates them. We also present a formal semantics for the new language, and we describe an implementation for MzScheme.
To me, an interesting aspect was interleaving of overrides and augmentations of the same method.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Description of related work incorrect

The discussion of CLOS in Section 6 is incorrect. The authors make two claims:

  1. They state that CLOS can simulate inner calls with :around methods, but that one cannot have multiple inner calls that move down a class hierarchy, from least specific to most specific class.
  2. The also state that CLOS does not allow to have both super and inner calls within the same method (like call-next-method and call-inner-method).

Both claims are wrong:

  1. Multiple inner calls can be implemented in 'pure' CLOS by way of a user-defined method combination. Just take the example from the Common Lisp specification that implements the default method-combination technique and reverse the order of the :around methods.
  2. The BetaJava model can be implemented in about 100 lines of CLOS when a conforming CLOS MOP implementation is available, as specified here. If there is interest, I can post the code somewhere.


I have pasted an updated version of the CLOS implementation of the BetaJava model. Happy new year. ;)

They have been together for a while

We have actually had super and inner in Moose for over 3.5 years now. This paper was actually one of the inspirations for adding inner.

i don't entirely follow

when reading the paper, my small mind balked at the complexity, and i felt like there should be a different abstraction that would better be used for the example in the paper. like, use layers/regions so that a subclass of BorderButton can't screw up the border. or something.

Template methods

I agree that the example is not the most convincing.

It may help to think of "inner" as language support for template method pattern (and template methods are abundant in both Java and .NET libraries).


Calling "inner" is the same as calling an initially-empty function that gets overriden in subclasses, isn't it? In that case, other than solving naming difficulties I don't see much use in the scheme.

Or for that matter using

Or for that matter using super in conjunction with Ruby-style blocks.

Not the same

Inner calls search down the class hierarchy from the top, unlike regular method calls which start at the bottom.

Matryoshka dolls

Well, that's because every function that calls inner spawns a new empty function.

I will concede that naming issues become quickly a nuisance if you see it that way.