Language design

Wes Garland wes at page.ca
Sun Jun 14 11:24:56 UTC 2015


> That root post ignored compatibility constraints that have been discussed to death over the years, and just glibly asserted that == and === could be changed.

The last time == and === were changed (JS 1.1-1.2-1.3) I was a pretty
green developer building a very large DHTML application. I lost many
nights of sleep trying to figure out why my code worked on one version
of Netscape but not the other.  You can't change stuff like that, we
have paid the price to learn that lesson!

The OP also spoke about fromCodePoint vs fromCharCode.  It is
necessary, IMO, to be able to manipulate both the underlying bytes and
Unicode. I bumped into a related issue on our Server Side solution
this week, importing malformed UTF8. Our platform has a big switch
which changes how we handle C strings, and both modes of operation
were necessary to analyze and resolve the problem.

I'm looking forward to upgrading to ES6. I'm building large, somewhat
complex, applications that share ES5 libraries and data on the browser
and server. I am looking forward to features like default parameters,
destructuring assignment (we have this in the server and like it),
better modules (although there will be migration pain), and template
strings.

I'm sure there will be stuff I don't need - but that's okay, I just
won't use it.

Wes


> So, I don't believe you agreed with that noise. Am I mistaken?
>
> If your point is that Object.is does not pull its weight, make a stronger case for why people should have to write it by hand.
>
> You missed that Object.is(-0, +0) (and with arguments transposed) is false, while -0 === +0.
>
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list