3 ms·
codePointAt still takes the same type of index that charCodeAt does. It doesn't address the issue at all. $ jsc >>> '\u{1f4a9}A'.codePointAt(1).toStrin
by pwdisswordfish 9y ago
codePointAt still takes the same type of index that charCodeAt does. It doesn't address the issue at all.
$ jsc
>>> '\u{1f4a9}A'.codePointAt(1).toString(16)
dca9
And what was the committee supposed to do with all those string indexing functions that have existed since LiveScript times, remove them? Change their semantics overnight and break countless software in the process?
If there's any thing JavaScript has been doing right so far, it's backwards compatibility. For better or for worse.
- carussell 9y agoI thought it would have been clear from my comment that I don't regard the new ES6 methods as flawless.
- twic 9y agoThis doesn't seem insurmountable. Three steps: 1. Introduce new methods which allow access to code points without indexing by UCS-2 code unit. An iterator over code points is the key thing. You could also have some opaque kind of index, with a method to get a list of indices for every code point in the string, and then a method to look up a code point by opaque index. The former could be expensive, as it would involve scanning the string to find where each character starts (although perhaps that could be done lazily?), but the latter should be cheap. The results of the expensive method could be cached. 2. Wait N years for the new methods to be widely adopted. 3. Shift the internal representation of strings to UTF-8. Anyone using the new methods will see similar, or better, performance. Anyone using the old methods will see a drop in performance. Implementations could even dynamically choose between representations based on usage patterns. The fact that each web page is its own little JS universe should make that fairly practical.