Minimalist Classes

[Brendan Eich]

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 rauschma.de> 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. super.foo()) 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 https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js#L419 

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  this.do and super.do 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 super.foo() or super.bar(). It may be good practice most of the time, but it's not dogma.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111101/b00278e4/attachment.html>