Tab Atkins Jr. wrote:
On Sun, Jul 21, 2013 at 9:25 PM, Brendan Eich<[email protected]> wrote:
Tab Atkins Jr. wrote:
In reality, only the web-exposed parts are,
What is not web-exposed here, pray tell?
The parser itself. Only the results of the parser are, in terms of
observable program behavior and presence/absence of syntax errors.
This is irrelevant, since the change you are proposing is a
compatibility-breaking one, even though parse trees are not yet reflectable.
and
then only the parts that the web actually depends on.
This is the part we can't determine. "The web" is not just the
Google-indexable (by what user agent?) part, but paywalled and intranet
content as well. I've written before that finding true positives helps
reject a proposed incompatible change, but finding no positives does not
prove that we can make the change.
Furthermore, the first browser to roll the dice and face breakage loses,
making implementors generally unwilling to take even likely-small risks.
This browser Prisoner's Dilemma can be helped by cooperation, e.g., among
TC39ers, but even then only for a big enough payoff. See the typeof null ==
"null" attempt early in ES6 development for an example.
Preaching to the choir, buddy - I've been standardsing for quite a
while too.
So why were you preaching at Rick? I didn't want to reply, but at some
point the one-sided arguing got to be too much.
Look, you're proposing an incompatible change, akin to typeof null's
result change. It doesn't matter why people might write code you'd
break, it matters how much code exists. That's an empirical question.
Exhorting people here does nothing but annoy some of us.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
