- From: Joshua Bell <jsbell@chromium.org>
- Date: Mon, 6 Aug 2012 12:38:36 -0600
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Sun, Aug 5, 2012 at 10:29 AM, Glenn Maynard <glenn@zewt.org> wrote: > > I guess the brokenness of Uint16Array (eg. the current lack of > Uint16LEArray) could be sidestepped by just always returning Uint8Array, > even if encoding to a 16-bit encoding (which is what it currently says to > do). Maybe that's better anyway, since it avoids making UTF-16 a special > case. +1 - which is why I pushed back on returning a Uint16Array earlier in the discussion. > I guess that if you're converting a string to a UTF-16 ArrayBuffer, > you're probably doing it to quickly dump it into a binary field somewhere > anyway--if you wanted to *examine* the codepoints, you'd just look at the > DOMString you started with. > +1 again, and nicely stated. When I was a potential consumer of such an API, I was happy to treat the encoded form as a black box.
Received on Monday, 6 August 2012 18:39:05 UTC