Mark S. Miller wrote:
I think that
o.{
p1: expr0,
p2() {return this.p1},
get p3 () {someSideEffect(); return this.p1}
};
and
o.(
p1 = expr1;
p2());
p3 //I didn't include this case in the bnf I wrote up
}
are syntacticly distinctive enough that there would be no reason
to trade them off against each other. They should each be
consider based upon their unique utility. An advantage of my
recent strawman (and what we discussed at the TC39 meeting) is
that it leveraged one construct for a larger number of use cases.
That is generally a good think, if it doesn't create confusion.
Unfortunately may strawman may not meet that mark.
If you are concerned about the overall syntactic complexity budget
of the language, then we aren't limited to only trading the above
two constructs off against each other. There are other new and
relatively complex syntactic embellishments that we have adopted
that IMO may not have as much general utility as either of the
above. If we are concerned about the syntactic complexity
budget, we should be looking globally at all the proposals. But,
that is another conversation.
My concern is indeed the overall complexity budget. And I agree. I'm
happy to have both of these if we can make some real complexity cuts
elsewhere. I look forward to that other conversation ;).
I think this is too blind of the particulars. We shouldn't bean-count
when complexity-budgeting because we can get stuck hill-climbing at a
local maximum where there's a better hill to climb just over the
horizon. My TXJS talk last year went on about this a bit too much but it
is a recurring theme.
I would say we should cater to [[Put]] common cases with custom syntax
first, and wait for extend-with-accessors use-cases to feel some pain
from having to use the ES5 Object APIs. So I agree with Nicholas, Tab,
and Dave.
Further, you and I agree syntax should distinguish distinct-enough
semantics, so no : for [[Put]], rather =. We both like the Smalltalk
homage. Dave reminded me of how the {}-bracketed form looks nicer than
the () form, though, because it looks like a (restricted as to parse
tree children) block.
I'm ok with either, but that means I must come down against mustache as
proposed -- obj.{prop: val, get x()..., m() {...}}. I don't see the
define instead of assign use-case as deserving this syntax, and now that
Dave has recapitulated it, the imperative update hiding in declarative
syntax rubs me the wrong way too.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
