Minimalist Classes

Brendan Eich brendan at
Tue Nov 1 12:53:38 PDT 2011

On Nov 1, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:

> On Nov 1, 2011, at 12:27 PM, Jeremy Ashkenas wrote:
>> On Tue, Nov 1, 2011 at 3:21 PM, Axel Rauschmayer <axel at> wrote:
>> Another problem: What if an instance method makes a super-call?
>> A slightly less elegant (and performant) variant of your solution that works in both of the above cases is:
>> - Keep track (per object and method) of the object where the previous super-call (e.g. ended up.
>> - Start your search either there or at |this|: look for the *second* occurrence of property "foo". [optional: optimize non-|this| case]
>> Nope -- I think that design isn't the correct semantics. super() exists to delegate back to parent implementations of *the current method*. When calling a different instance method the calls should always start back out at the bottom of the inheritance hierarchy -- not at whatever level you happened to be on at the time.
> Who says?  See 

Ruby vs. Smalltalk -- FIGHT! :-P

> Note that this is a direct transliteration of code from one of the first and longest lived object-oriented class libraries (see comments at the head of the file).  So super calls to "other methods" have a long history.  It is a relatively rare technique, but sometimes it is essential.  In this particular case, a super call to the same method would produce a loop.  In this case choice of doing and needed to be made by the original programmer based upon their decomposition of methods. 

I agree, it's not necessary to restrict the super special form to super() instead of or It may be good practice most of the time, but it's not dogma.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list