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_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
