Alternative syntax for <|

Russell Leggett russell.leggett at gmail.com
Thu Nov 17 13:56:27 PST 2011


>
> 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.
>

Yes, I guess it would not be an operator at that point, but I had thought
that much the same way that function can be used as a declaration and an
expression, class could be used as a declaration and an operator. Perhaps
this is confusing or impossible. Seemed doable to me.


> 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.
>

Yes, sorry. I should have said "To my limited knowledge, ...". I had not
seen that as part of any proposal, but I haven't read them all or as
thoroughly as I could.


> 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/32a47204/attachment.html>


More information about the es-discuss mailing list