On Feb 20, 2012, at 1:42 PM, Wes Garland wrote:
> On 20 February 2012 16:00, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
>
> ...
> Observation -- disallowing otherwise "legal" Unicode strings because they
> contain code points d800-dfff has very concrete implementation benefits: it's
> possible to use UTF-16 to represent the String's backing store. Without this
> concession, I fear it may not be possible to implement BRS-on without using a
> UTF-8 or full code point backing store (or some non-standard invention).
(or using multiple representations)
>
Yes, I understand. If it is a requirement (or even a goal) to enable
implementation to use UTF-16 as the backing store, we should be clearer about
it being so.
> Maybe the answer is to consider (shudder) adding String-like utility
> functions to the TypedArrays? FWIW, CommonJS tried to go down this path and
> it turned out to be a lot of work for very little benefit (if any).
>
> But with the BRS flipped it would have to censor C "strings" passed to JS to
> ensure that unmatched surrogate pairs are present.
>
> Only if the C strings are wide-character strings. 8-bit char strings are
> fine, they map right onto Latin-1 in native Unicode as well as the UTF-16 and
> UCS-2 encodings.
Yes, I was assuming WCHAR strings
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
