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

[whatwg] API for encoding/decoding ArrayBuffers into text

From: John Tamplin <jat@google.com>
Date: Mon, 26 Mar 2012 21:21:34 -0400
Message-ID: <CABLsOLCM0KKhZOyAM=n+FDsKq8P56UimS4i27pbZeeO_jTSZuw@mail.gmail.com>
On Mon, Mar 26, 2012 at 9:11 PM, Kenneth Russell <kbr at google.com> wrote:

> The rationale for specifying the string encoding and decoding
> functionality outside the typed array specification is to keep the
> typed array spec small and easily implementable. The indexed property
> getters and setters on the typed array views, and methods on DataView,
> are designed to be implementable with a small amount of assembly code
> in JavaScript engines. I'd strongly prefer to continue to design the
> encoding/decoding functionality separately from the typed array views.
>

However, if the browser's don't all implement this, then you can't rely on
it being there.  In apps where you compile separately for each browser, you
only pay the cost where the browser doesn't implement it (for example, in
GWT we emulate DataView and Uint8ClampedArray where it is missing).  Even
then, you may have to include both versions and do runtime detection, such
as when later versions of the browser include the functionality -- that may
be worse than simply not using the API at all if you care more about code
size than execution speed of encoding/decoding text.

So, personally I think whatever gets the most browsers to completely
implement it is better, whether that is being part of the typed arrays spec
or separate.  Logically, it seems to fit most directly in DataView.

-- 
John A. Tamplin
Software Engineer (GWT), Google
Received on Monday, 26 March 2012 18:21:34 UTC

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