typed array strawman proposal
vladimir at mozilla.com
Wed Jan 27 10:56:14 PST 2010
On 1/26/2010 11:25 PM, Kris Kowal wrote:
> On Tue, Jan 26, 2010 at 10:43 AM, Vladimir Vukicevic
> <vladimir at mozilla.com> wrote:
>> At Brendan's request, I've just added a new strawman proposal for ES typed
>> arrays to the wiki. This proposal comes from the WebGL group, which needed
>> a way of efficient access to and manipulation of native machine-type arrays;
>> once we came up with a reasonable baseline API, it looked like something
>> that would be generally useful as more interop and performance demands are
>> placed on ES. "Typed arrays" is probably not the best name; but that's
>> probably an easy bikeshed.
> I've made three similar proposals over in CommonJS.
> ArrayBuffer is a strict subset of what I'm calling ByteArray (which
> incidentally fits the TypeArray pattern you establish in your
> proposal). I think we could converge these proposals. Yours is most
> similar to Binary/B. Binary/D adds some bit types and improved the
> details a bit. Bineary/E abandoned the notion that binary types could
> become natives in CommonJS, removed the bit types, and reduced the API
> significantly again.
It's actually somewhat different -- ArrayBuffer is just a raw buffer
store with no ability to access its data directly. One of the
/Type/Array objects need to be created to access it, in this case a
Int8Array (or Uint8Array, depending on what you mean by "Byte").
We briefly considered making ArrayBuffer and Int8/Uint8Array the same,
and letting you layer views on top of *8Array buffers, but it became
more of a pain from an API design point of view. Having a separate
"opaque buffer" type really simplifies both this API and any methods
that want to use it -- if they don't care about the type of data, and
just deal with raw binary buffers (e.g. network send/receive, file read,
etc.) they can expect an ArrayBuffer. If they have an explicit need for
a particular type (e.g. WebGL expecting an array of 16-bit ints), they
can require the specific type(s).
> To get closer to your proposal, it would probably be easier to start
> from yours and add rather than start from one of mine and subtract. I
> recommend ByteArray for the name. It matches the pattern you
> establish for Integer Arrays. Secondly, I think "slice" needs to
> return an immutable fixed length type, or ought not be included.
Everything is fixed-length here, though I'm not sure what you mean by
immutable -- ES Arrays' slice returns a mutable array. The issue with
slice() as currently specified on /Type/Array is that it returns a view
of the same underlying ArrayBuffer, so changes in the sliced array are
visible in the original. This is inconsistent with ES arrays, and could
be a source of confusion. Naming this range() as you suggest is
probably much better, and perhaps retaining slice() to make a copy.
However, with the API as written, current-slice() (range()) is trivially
implemented already (ignoring negative indices and range, but...):
new Uint8Array(origArray.buffer, origArray.byteOffset + startIndex,
endIndex - startIndex);
And assuming range(), a real slice() would be: new
More information about the es-discuss