extends keyword instead of <superclass ... >

Brendan Eich brendan at mozilla.com
Sun Mar 27 22:31:27 PDT 2011


Hi Allen, all good points. A few thoughts below, interspersed.

On Mar 27, 2011, at 4:39 PM, Allen Wirfs-Brock wrote:

> At the latest TC39 meeting some participants expressed an opinion that the prototype specification for an object literal should go outside of the brackets.  http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator presents one possible design for that approach.

That strawman is essentially functional record update for setting __proto__ AKA [[Prototype]], although it reads backwards compared to FRU in ML-family languages. Those languages put the update on the right, often linked using 'with' (hah!).

As you note in the strawman, this enables proto-presetting for a number of built-in classes, not just Object and Array.

I'm warming up, modulo the backward sense of the connective (also, you need a [no LineTerminator here] to the left of ''proto'' in the productions). Thinking outside the box, indeed.

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, ...};

should be supported.

So, infix operators or magic property names?

For classes, at any rate, it seems to me that On the Outside and Declarative may be at odds, since initialisers are expressions. More below on why.


>> The strongest case for extending initialiser syntax is that it is "nearly declarative" today. That suggests strongly making the extension fully declarative, i.e., not usable as an expression. And that, all else equal (never is, but:) says to consider class D extends B {...}. My 2 cents.
> 
> I don't think "declarative" should not be equated with "not usable as an expression " or introduces a lexical binding.

It's not clear that classes need to bind their names, or even need names. I believe that some on TC39 want non-generative, nominal run-time types via classes. Others may want generative expressions.

The consistent #1 request from users that I've heard over the years, most recently in my blog comments, has been for a declarative form of JS's prototypal object-oriented pattern. This conventionally means a new binding. It's generative if you nest it in an outer function, which is not a problem, but usually it is not nested, or else nested only in an outer IIFE (aka the module pattern).


> Both function declarations and function expressions are both declarative definitions of functions

Here is a bit of a nit, but calling both declarative even though one is an expression, not a declaration, sounds like a contradiction, or a redefinition of "declarat{ive,ion}".

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.

You're right that expressed as well as declared (whether top-level or not) forms could be supported. The question for classes is whether we would ever want an anonymous or named class expression. Just because 'function' can do that does not mean that 'class' must.

I'd love to hear from Waldemar and MarkM on this point, since I suspect they have something (or things, not necessarily the same) in mind.

> even though one creates a local binding and the other can be used as an expression.  In my proposal, the same distinction was applied to class definitions.  There was both a statement and expression form, largely for consistency with functions.  I don't think this distinction has much, at all, to do with the syntax for specifying the superclass or prototype.

Agreed.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110327/a05c2795/attachment-0001.html>


More information about the es-discuss mailing list