Andy Earnshaw wrote:
On Mon, Jul 22, 2013 at 5:25 AM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
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.
typeof null == "null" is a different case though. typeof is a
requirement for checking the existence of pre-declared variables, so
you could expect something like, if (typeof someVar === "object" &&
someVar === null), to appear at least in a few places on the web.
Tab's saying that this proposal wouldn't break much (if anything)
because code isn't written like this anywhere: it wouldn't be readable
or reliable. Writing a < b < c in ES<=5 would be either stupidity or
ignorance (in the case of the latter then this proposal would probably
fix more code than it breaks).
You're committing a category error here. It doesn't matter *why* someone
does something on the web, it matters *how much* the standard semantics
are required by "working" code (scare quotes on purpose).
In other words, you can't reason about this _a priori_ only and reach a
conclusion that "we can get away with a breaking change". Such "we can
get away with" claims require _a posteriori_ experiments and
potentially-market-share-losing results, too.
For equality, there might be a problem where code is written like, if
(a === b === true), where a and b are something other than booleans.
I could maybe see an outside chance that this appears somewhere on
the web or an intranet, but maybe there's a way we can deal with it so
it doesn't break backwards compatibility.
"use chained comparisons";, anyone? ;-)
We could add more pseudo-pragmas but they must not add runtime checks
(so this one would be ok by that constraint), and we'll have a wicked
fight justifying any additions that aren't strongly motivated.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
