On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
>
>> I don't think we need any "safety check" when assigning a method or
>> accessor getter or setter that uses super to an object. The concept
>> of "super" seems to be a relative one,
>
> That is what we are arguing about. It's not a conclusion we all share.
In ES, functions are first class objects not owned by any one object,
an "absolute" super breaks this.
>
>
>> it is the object one step up in
>> the prototype chain from the current object.
>
> The "current object" -- Axel's |here| -- is not exposed in JS. Exposing it
> requires another implicit parameter, which costs too much.
>
I'm not suggesting that |here| be exposed just |super|.
The |super| I am suggesting is not an "additional implicit parameter",
it's just a value that is determined while walking the prototype chain
of the existing |this| implicit parameter. Why would this value be
more expensive to access when resolving |super| in the function
activation than the [[Super]] internal property of the function would
be?
>
>> If a method or accessor
>> getter or setter needs an *absolute* reference to the prototype of a
>> given object, it should refer to it by name.
>
> Agreed, especially when mutating. Bu the relativity of |super| is still in
> dispute (relative to what? when?).
>
>
what: object on which the property was found
when: during prototype climbing
>> Thus, in both cases it will just be a matter of accessing an
>> internal property of an object that is immediately accessible when
>> climbing the prototype chain.
>
> Here you seem to assume the |here| result found during callee-expression
> evaluation in your proposal can be stored in [[Super]]. That's still an
> implicit per-call parameter (an even less efficient way to pass it, by
> side-effecting the called function object, but never mind!). The problem is
> the per-call overhead.
>
No, I'm not suggesting to store the |super| ( |here|.[[Prototype]] )
result permanently anywhere, just to keep it accessible during the
function activation. The value has already been calculated via the
prototype climbing, what is the overhead in keeping it around?
> /be
>
>
>>
>> On Tue, Jun 21, 2011 at 3:55 PM, Brendan Eich <bren...@mozilla.com> wrote:
>>> On Jun 21, 2011, at 11:53 AM, Brendan Eich wrote:
>>>
>>> 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().
>>>
>>> Example:
>>> C.prototype = {
>>> foo() { addedValue(); return super.foo(); }
>>> ...
>>> };
>>> x = new C;
>>> x.foo(); // oops, diverges in endless self-recursion.
>>>
>>> Now, with the static 'super' semantics plus Object.defineMethod(O, 'foo',
>>> C.prototype.foo), you can rebind 'super'.
>>> One thing I'm not sure about: whether Object.defineMethod should mutate
>>> C.prototype.foo's internal property, or make a new function object with a
>>> different 'super' binding.
>>> In any case, the static and internal-to-method semantics avoid the infinite
>>> recursion hazard, and they avoid the cost of an extra parameter beyond
>>> |this|.
>>> /be
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> Cheers,
>> Sean Eagan
>
>
Cheers,
Sean Eagan
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
