[Bug 23369] Provide hooks for Typed Arrays

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

Joshua Bell <jsbell@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |23332

--- Comment #2 from Joshua Bell <jsbell@google.com> ---
Marking as "blocks https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332" since
if we decide anything here it will change how that API should be defined. It's
another "operation needs a byte sequence" API, like encoding.

Agreed w/ BZ that we do not need new syntax/names here. It seems to me that we
should agree on what this (growing?) class of operations should accept so they
are consistent.

In these APIs, the type of the view is unimportant and potentially misleading -
if a caller passes a Float32Array the floats are ignored and just the
underlying bytes are used.

A few possibilities:

#1: operation( (ArrayBuffer or ArrayBufferView) byteSequence );
#2: operation( ArrayBuffer byteSequence );
#3: operation( ArrayBufferView byteSequence );
#4: operation( DataView byteSequence );
#5: operation( Uint8Array byteSequence );
#6: operation( (ArrayBuffer or Uint8Array) byteSequence );

#1 lets you pass in a buffer or a view on a buffer.
https://bugzilla.mozilla.org/show_bug.cgi?id=796327 indicates
window.ArrayBufferView is being removed (which would complicate polyfills) and
ArrayBufferView is not in the ES6 drafts. Can it still be used in IDL? If not
this would need to become a union of all the array types i.e. (Int8Array or
Uint8Array or Uint8ArrayClamped or Int16Array or ... or Float64Array).

#2 forces the caller to have a raw "array of bytes". If operating on a subset
of a larger buffer this requires a copy. Bleah.

#3 is possibly problematic for the same reasons as #1. (FWIW, this is what
TextDecoder accepts today)

#4 uses the type-agnostic DataView, most commonly used for encoding/decoding
structs/files. In the abstract this seems more correct than many of the other
options, but it's one more concept for developers to learn.

#5 anoints Uint8Array as "this is a byte sequence". It's akin to saying "in
this C++ project, a we hold a sequence bytes in a std::vector<unsigned char>",
for the web platform. (And I'm okay with that, but others may object)

#6 is a slight compromise on #5 that avoids having to new Uint8Array(buffer) if
you already have an ArrayBuffer from another source. This seems like API
clutter to me. 

If we e.g. agree on #5 for this class of APIs then we don't need anything new
in IDL - it's Uint8Array in and out from these operations.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 26 September 2013 17:07:20 UTC