typed array strawman proposal

Michael Daumling mdaeumli at adobe.com
Wed Jan 27 00:20:27 PST 2010

For this proposal, I would not use the term ByteArray. It may lead to confusion with existing definitions of ByteArray, such as in ActionScript, where a ByteArray is a wrapper around arbitrary binary data. The ActionScript ByteArray APIs are file oriented, with members like readInt() or writeUTF(). A Google search for ByteArray returns several hits around the ActionScript ByteArray; it is a widely accepted construct to wrap binary data.

In .NET, a ByteArray is not a distinct object, but just a blob of byte data in the context of data transfers between a device and a PC.

I am unsure about the intent of JS ByteArrays. To me, the proposal looks like an Array implementation, where all elements are guaranteed to be of the same type. If this is the intent, then fine. But if the intent is to offer wrappers around native arrays, which would actually be memory areas of elements of the same type, why stick to the Array notation and semantics? Why not define a Vector object that may share a subset of the Array functionality, but that would be guaranteed to be a fast and memory-saving implementation?

Please enlighten me.


-----Original Message-----
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Kris Kowal
Sent: Tuesday, January 26, 2010 11:26 PM
To: Vladimir Vukicevic
Cc: es-discuss at mozilla.org
Subject: Re: typed array strawman proposal

On Tue, Jan 26, 2010 at 10:43 AM, Vladimir Vukicevic
<vladimir at mozilla.com> wrote:
> Howdy,
> 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.

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.
Daniel Friesen proposed a "Range" type and a "range" method in
Binary/C which I incorporated in D and E.  "range" is like slice but
returns a view of the underlying buffer region and supports the
relevant subset of the ByteArray API.  With "range", there is no
expectation of indefinite consistency.  I think the various aligned
typed arrays are a good idea, but I think CommonJS would be satisfied
if we were to agree on the byte array buffer type initially.

Kris Kowal
es-discuss mailing list
es-discuss at mozilla.org

More information about the es-discuss mailing list