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 <[email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
