Making "super" work outside a literal?

Brendan Eich brendan at mozilla.com
Tue Jun 21 11:53:59 PDT 2011


On Jun 21, 2011, at 11:33 AM, Oliver Hunt wrote:

> I'm answering some of the performance questions in this, but i don't know what the intended semantics of 'dynamic super' would be so I can't give specific details of most of the use cases.  If it's essentially sugar for super.foo => Object.getPrototypeOf(this).foo (with appropriate munging for calls, etc) then the cost is at point of use only, but if it's anything more fun (there are references to additional implicit parameters below which would be fairly bad for performance of calls)

That's the point: super must mean something other than Object.getPrototypeOf(this). Otherwise with the prototypal pattern you will infinitely recurse calling the same prototype-homed foo from foo via super.foo().

If super was shorthand only for Object.getPrototypeOf(this), then there's hardly any point in making super short for that expression.

Axel's notion of a |here| object helps, in that Object.getPrototypeOf(here) is more what you want from 'super' -- but not necessarily when the method has been borrowed by another object used as |here|. Note the "necessarily" -- you may know how to rebind 'super', but you may not. Allen's Object.defineMethod requires an affirmative defense before you can rebind super. It's a safety step, since 'super' is an internal function property and *not* a free parameter.

BTW I do not agree we can or should try to reserve 'here' or expose the method's "home object" -- that breaks abstractions built using prototypes. 'super' does not, because it always goes to the [[Prototype]] of the object in which the method was defined.

/be

> 
> On Jun 21, 2011, at 11:04 AM, Sean Eagan wrote:
>> I disagree that a dynamic super would lead to a '50% increase in
> 
>> argument passing overhead, on average'.  First, there is the implicit
>> 'arguments' argument, which is an object that actually needs to be
>> created per call site, not just a binding, and thus is presumably much
>> more expensive.
> Nope, creating an arguments object is on average free, as most uses can be lowered.
> 
>> Second, 'argument passing overhead' involves sunk
>> costs that are not dependent on the number of argument bindings that
>> need to be created.
> Every additional argument has a performance cost
> 
>> Third, implicit arguments, as 'super' would be,
>> should be less costly than explicit arguments since the argument value
>> does not need to be resolved.
> 
> I haven't really been following this but why does super need to be passed as an additional parameter?
> 
>> 
>> A better estimate of the overhead of dynamic super would probably be
>> the overhead of an implicit 'this' binding, i.e. the cost of creating
>> a 'this' binding for a function activation that not involving an
>> explicit 'this' via Function.prototype.call or
>> Function.prototype.apply, or Function.prototype.bind.  Does anyone
>> have any estimates of this cost, either absolute or relative to some
>> other cost?
> 
> That depends on the exact use case.  JSC doesn't determine what |this| is at the callsite (In general strict mode makes that impossible), so it becomes a question of whether you use it or not.
> 
>> I was unaware that dynamic super had been discussed, proposed, or
>> attempted previously for ES, or that it was ever included to have
>> 'pervasive overhead'.  Do you any references for this?
> 
> No idea -- it would depend on what the actual semantics of super were
> 

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


More information about the es-discuss mailing list