> Anyway, my point is that decorators in front of functions and classes or
> other declarative forms work. In front of every property assignment in an
> object literal? Not so much.
The defaults outlined in “Object Literal Extensions” should work well, I
especially like the shorter syntax for methods. What other needs are there?
@const (=non-configurable and non-writable) and @private? That would move
things a little more into the direction of Java, but I wouldn’t mind that. A
little more verbose, yes, but one would also immediately understand what is
going on.
> It may be that we require @decorators to start on a new line (with leading
> horizontal space allowed, of course), in order to enable @ as an operator in
> expressions where [no LineTerminator here] would apply to the left of the @.
That makes sense. I always format my code like this, anyway. Syntax coloring
displays them in gray which greatly minimizes *perceived* clutter.
> What are the few special characters that you can handle, right now, as
> additions mooted for JS?
I can handle everything except for some of the proposed object literal
shorthands (see code at the bottom of this email). Read on.
> Quasi-literals rule, and `` is the right quoting system given the characters
> left that can be easily typed and that don't ding readability.
Yes, I love them and hope that assignment via ${=x} makes it into ES.next,
because that’ll enable us to do all kinds of matching.
> We have <| but it is a bit contentious. No one has topped it, though, and a
> keyword instead seems to lose on both restricted-production and
> no-better-word-than-<| grounds.
I like that one, it’s very visual; I find it more descriptive than the keyword
"proto".
> Some find -> and => cryptic, but it's hard to say the only alternative is to
> stick to eight-letter 'function'. ('lambda' is not reserved and can't be used
> without breaking compatibility; and it's six letters.)
>
> Some find block-lambdas with their Ruby- (and to a lesser extend Smalltalk-)
> inspired {||...} bracketing cryptic.
- Pro block-lambdas: A new construct that can be used in places where dynamic
|this| (that normal functions are always going to have) would be a burden.
- Pro arrows: little semantic change. With the shorthand for methods in object
literals, there is the question whether dynamic |this| is ever needed. But if
we need both dynamic and lexical |this|, then the arrows are nice in that they
look similar, but are still different.
- Pro ƒ: short, syntactically very similar to current semantics *and* syntax.
And as easy to type on a German Mac keyboard as curly braces and square
brackets. But I respect the reasoning against it and am in awe that you still
have the patience to discuss this kind of issue.
> There are other options, but they all face genreric "too much line noise!"
> objections.
Programming language syntax is in the same category as politics and religion:
There are few simple compromises.
This is me being oblivious to many of the gory details, but if only my taste
mattered, then I would do the following:
==== Instead of (example in the proposal) ... ====
var obj = theProtoObj <| {.seal,
~konst:= f(),
handler: defaultHandler,
~get super set name(v) {throw Error("some message")},
source() {throw Error("another message")},
toString() {return "d "+super.toString()}
};
==== ... write the following ====
var obj = theProtoObj <| {.seal,
@const
konst: f(),
handler: defaultHandler,
get name() {
return super.name;
},
set name(v) {
throw Error("some message");
},
source() {throw new Error("another message")},
toString() {return "d "+super.toString()},
];
==== Rationale ====
- Does enumerability ever matter?
- Passing the getter through to the super-class seems like a rare use case.
Doing so manually could be optimized by a compiler and while it is a tiny bit
verbose, it clearly expresses what is going on. The proposed shorthand is hard
to parse for me. Alternative:
get name() super,
set name(v) {
throw Error("some message");
},
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
