Leon Arnott wrote:
Well, they're a distinct special form that can be used in expression
position, and evaluates to a function, so they're definitely, to bring
back an old coin, quasi-literal. (I personally think your reasoning
entails that arrows aren't function literals because of their lexical
`this` bindings.)
(That doesn't follow, but let's not quibble -- in any case, "literal" is
the wrong word.)
The bigger problem is that we do not want class syntax for declaring
properties on the prototype, which is what
class C {
d: 42,
constructor(){}
}
would denote if you really mean object initialiser expressing the
prototype object as class body.
So, stuff inside class bodies should be considered more like function
statements, not property definitions - even though they have a lot of
*very* property-ish things, like computed names, or shorthand methods,
or accessors, or shorthand generators... :|
It's neither fish nor fowl.
Special forms are special, they mean what we say. Of course we should
use good taste and clear precedent where we can. I'm saying object
initialisers are not good precedent, and false taste (like fake sugar --
saccharine!).
And, according to that gist, data properties should be considered to
be like assignment statements. Would that make a hypothetical `class {
[foo, bar] = [1,2]; }` a destructuring or a computed property name?
Either answer seems dissatisfying (the former because it precludes the
latter; the latter because it mis-resembles the former).
The proposal from Jeff is just a straw item for ES7, but it seems better
than using data property syntax (see above). It'd still be a special
form, so restricting the LHS to exclude destructuring patterns is not
hard on either grammar or users.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
