W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2012

Re: [whatwg] StringEncoding: encode() return type looks weird in the IDL

From: Joshua Bell <jsbell@chromium.org>
Date: Mon, 6 Aug 2012 12:38:36 -0600
Message-ID: <CAD649j567fbQ=GcVJAE+7K+G+J=QBowHEJ4-5srjdKbVS-G5XQ@mail.gmail.com>
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

>  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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:44 UTC