Making "super" work outside a literal?

Allen Wirfs-Brock allen at
Thu Jun 23 06:48:35 PDT 2011

On Jun 23, 2011, at 12:31 PM, Axel Rauschmayer wrote:

>> This is entirely beside the point.
>> Dynamic |super| as Sean proposes requires *every call site* to pass the |here| parameter or something derived from it, no way around that.
>> Paying for 'super' if you use it, buying by the yard, is not a problem.
>> Making *every function call* in the language slow, increasing register pressure, etc. -- absent aggressive inference to identify callees and specialize call sites to them (inlining VMs do this but it can backfire, so there will be a default case that can't do this) -- is a big problem.
> I believe you about the dynamic super. I can summarize my question as follows:
> - Making "super" or "current object" available to a function incurs costs.
If it is statically bound (via a [[Super]]  or [[Current]] internal property then there is only a cost (and a small one) on actual accesses of super.  EG,
   Object.defineMethod(obj,'foo", function() {return /*cost to access [[Super]] + cost to access this */});

If dynamically bound (on each property lookup of the method)  then there is a cost on every function call to pass the current object reference to the function invocation.  This cost is in addition to the const of passing thethis reference.

> - Making "current function" available to a function does not incur costs? This is *not* an extra parameter, then?

the current function is made available via the function name in a function declaration:
  var q= -1;
  Object.defineMethod(obj"foo",function bar(a,b,c) {return q*bar.length /* returns -3 */});

bar is a lexically scoped binding just like q.  No per call perimeters are involved.  The cost to access bar is approximately the same as the cost of accessing q (exact costs subject to details of how lexically scoped access is implemented)


More information about the es-discuss mailing list