extends keyword instead of <superclass ... >

Brendan Eich brendan at mozilla.com
Mon Mar 28 17:36:40 PDT 2011


On Mar 28, 2011, at 12:29 PM, Allen Wirfs-Brock wrote:

>> Dmitry's suggestion of #proto or a similar sigil-distinguished name makes me wonder, though: could we have FRU via the spread operator *and* proto presetting without adding a funky [no LineTerminator here] proto infix operator?
>> 
>>   var original_o = ...;
>>   var o = {#proto: p, ...original_o};
>> 
>> Given this, if you don't have an original_o to specialize (say, a RegExp or other built-in that can't be created via an initialiser), then of course
>> 
>>   var o = {#proto: p, key: val, ...};
> 
> or
>   var f= {#proto: p, ...function () {}};
>   var r= {#proto: p, .../[a-z]/};
>   var a={#proto: p, ...[1,2,3,4]);
> ???

I was not proposing only the last form that I wrote in the nested citation above: var o = {#proto: p, key: val, ...}.

My point was simply that the single-initialiser-with-some-proto form will be wanted as the basis case (no record to update) of an inductive case where there is a pre-existing record (object) to update with a specific proto.

In any event, spreading a function or regexp should not do anything magic with its internal properties. Using spread for FRU handles only enumerable own properties, reading a bit between the lines of the http://wiki.ecmascript.org/doku.php?id=strawman:records strawman.

Sorry, I didn't mean to drag records in here, just note how an ad-hoc proto operator seems like a specialized FRU if you buy Dmitry's #proto: p alterna-syntax.


> That is why in my proposal
>    class Foo {};
> is defined to mean almost exactly the same thing as
>    function Foo() {};
> (but things start to change when you put something between the brackets) and anonymous classes exist as an analog to function expressions.

Is the non-empty braced body an initialiser (extended) or a constructor code body? I'm on record against the initialiser extension for precisely this reason: function has a code body.


>> More substantive: if we want to enable optimizations and conveniences via syntax for the prototypal pattern, then declarations win, especially if they come with some ahead-of-time semantics, as top-level function declarations evaluated in a compile-and-go scenario do. Thanks to the order of function and then var declaration processing when entering an execution context, such a scenario supports the compiler pre-binding top-level functions.
> 
> I'm trying to relate this statement to the original "strongest case" comment above and I'm having a hard time. I probably something more concrete would help. 

If class C {...} is analogous to function in that each evaluation generates a new C and binds it to that name, where ... is constructor code, then the parallel to function is clear and implementations can optimize accordingly (as some already do for top level functions).

If {...} is an expression (initialiser, with extensions), then maybe the same optimizations apply at top level, but I'm not sure, and it doesn't look analogous to function any longer.

That's all. Not trying to make a mountain out of this, but either class C {...} is function-y or it isn't. Half-way in between, with an initialiser body, seems less good.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110328/891f50ba/attachment.html>


More information about the es-discuss mailing list