Alternative syntax for <|

Brendan Eich brendan at mozilla.com
Thu Nov 17 13:45:50 PST 2011


On Nov 17, 2011, at 1:34 PM, Russell Leggett wrote:

> On Thu, Nov 17, 2011 at 3:06 PM, David Flanagan <dflanagan at mozilla.com> wrote:
> On 11/16/11 11:45 AM, Erik Arvidsson wrote:
>> 
>> Sorry for being too brief. Today the following works.
>> 
>> f();
>> ...
>> function f() { ... }
>> 
>> but the following does not:
>> 
>> f();
>> ...
>> let f = function f() {};
>> 
>> I think it is important that we keep the forward reference behavior
>> with classes. This requires a declarative way of defining classes.
>> 
> I agree with Erik and Dave that forward references are critical for classes.  If we define syntax for classes that is less foward-reference friendly than functions are, it will be a source of bugs (speaking from personal experience) and be perceived as a step backward.
> 
> I agree forward references are important, and the way I see it, there are 3 levels of forward reference.
> 
> 1. variable hoisting - this can be done with var right now

'let' hoists to block top but it's an error in the current proposal to use the binding before the declaration (with or without an initialiser) has been evaluated.


>     var Foo = class {...}
> 
> This would allow a function body above it to reference Foo, but not call new Foo() until after it was defined. This is the limit of what Allen's operator proposal could do, even with a declarative form 'class Foo {...}' because it does not create a new function, it depends on the expression given to class.

Right.


> 2. function hoisting (did I make up this term?)

(You did not -- it's an ancient term and function hoisting always denotes the function being callable at scope top.)


> - a function declaration is capable of not only forward reference, but also forward calling, even before the declaration is reached in source order. This is the limit of what current constructor function based class declarations can do.

And actually *do* do -- and code counts on this, I believe. It's one of those things about classes-as-sugar that makes me want classes to hoist as functions do (functions in block are not specified by ES1-5 and implemented variously, but in Harmony and ES.next function in block hoists to block-top, both binding and initialization, and so would classes under this point of view).


> It is also something that my proposed version of the class operator could do, because it always creates a function, and could desugar to the same semantics as the current function style.

This may seem like a nit-pick, but I think it's not: any variant that sits at statement context in the grammar and has the form 'class C {...}' or 'class D extends B {...}' is not an expression using an operator. It's a class declaration.


> 3. class hoisting, where all members of the class are available would require a formal class body instead of an expression, and probably some restrictions on the class body definition. I don't think any form of class proposed so far would allow this.

Why not? Some proposals have either explicitly required (not allowed) this, or at least implied it.

Many proposals mirror function declarations vs. expressions by supporting all of class declarations (hoisted in some proposals as functions are, for the reason given above), named class expresssions (class name is usable in the class body but not head), and anonymous class expressions.

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


More information about the es-discuss mailing list