Making "super" work outside a literal?

Brendan Eich brendan at mozilla.com
Wed Jun 22 12:10:16 PDT 2011


On Jun 22, 2011, at 9:01 AM, Sean Eagan wrote:

> On Wed, Jun 22, 2011 at 10:35 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> Functions have static scope (see the [[Scope]] internal property). This is absolute and with very good reason!
> 
> Yes, functions have static scope, but functions (and all objects) do
> not have static owning objects,

The scope in ES1-5 can be an object, the global object. Your use of "owning" here either covers that case, in which your claim is false, or you need to define it better.

Many functions are used only as methods via prototypal inheritance, stored in one object (the prototype). Capturing that object's [[Prototype]] unambiguously via 'super' is useful. If it doesn't cover the dynamic case, use Object.defineMethod.


> they are free to be passed around and
> assigned as desired, this is what a static super breaks.

"breaks" is too strong. Object.defineMethod as a hard-case solution is being discussed. It's not the end of the world.


>> Your proposal requires another (implicit) parameter to functions taking super.
>> 
>> Since we do not know at the call site whether a function takes super, it requires an extra parameter for every call. This costs too much.
>> 
> 
> Its value is already resolved via prototype climbing,

Please, you are rehashing. We all agree on this. What is in dispute is the cost of passing this object as an extra implicit parameter.


>  I don't see the
> tremendous cost is simply making this value accessible within the
> function activation which occurs as a result of the prototype
> climbing.

Don't bring up arguments again. That object is optimized away in current engines for important cases, but it's a pain in the ass due to the required alias and escape analyses. We do not want more like that for 'super'.

The cost is naively an extra push or register, which is big enough that I can promise you: engine implementors will reject this. You are barking up the wrong tree here.

Want to clarify one thing: 'super' in the classes proposal has well-defined static meaning. I don't think you are trying to change that -- tell me if I'm wrong. 'super' in functions or methods in an object literal is what you're talking about.

/be



More information about the es-discuss mailing list