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

[Joshua Bell]

On Sun, Aug 5, 2012 at 10:29 AM, Glenn Maynard <glenn at 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.