On Sep 7, 2010, at 9:18 AM, P T Withington wrote: > On 2010-09-07, at 12:02, Brendan Eich wrote: > >> 3. identical > > If I had a vote, +1 > > Is there someplace that concisely explains the cost of just fixing `===` so I > could understand why that is not a choice?
The cost is hard to know without trying to fix ===, but potentially, even at low likelihood of breakage. No browser vendor is particularly motivated to try doing this, but it could be spec'ed and then we all try it "next time". I tried, in 1996 (shipping in 1997, Netscape 4 betas), to change == to act like === does now, in "JavaScript1.2". Developers had to opt in using <script language="JavaScript1.2">....</script>. In spite of the opt-in, this caused a lot of confusion due to code copying and dropped version specifiers. In the end, Microsoft did not implement this part of JS1.2 (RegExps and other parts made their way into ES3), and IE ignored script language= version selection (also for script type=, contrary to RFC 4329). In Ecma TC39 TG1, we ended up standardizing ES1 in 1997 with new === and !== operators, and == and != retained as the sloppy old non-equivalence relations. You could well argue that "fixing" === now, with better opt-in version selection machinery, would break less than my attempt then did, because it would entail fewer changes to go from === in ES5 to ===-as-Object.eq than what I tried in making == in JS1.2 mean what === means in ES1. But there's more to consider now: the web is wider and deeper, with greater depths hidden behind paywalls and registration barriers. Numerically intensive code, often driving canvas rendering and using transcendental functions (so potentially sensitive to -0 vs 0), is more common than ever. And tools and teachers promote === over == but of course cannot really do anything about -0 === 0 or NaN !== NaN. So I agree that it is worth discussing a change for === in Harmony, which requires opt in versioning, to mean what is proposed for Object.eq. But such a change still carries hard-to-quantify risk, which could impair migration efforts and (mostly) make TC39 swerve away from changing meaning in the Harmony version, instead playing it safe by adding a new API. Thanks for bringing this up. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
