typed array strawman proposal

Vladimir Vukicevic 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:
>    
>> 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.
>
> http://wiki.commonjs.org/wiki/Binary/B
> http://wiki.commonjs.org/wiki/Binary/D
> http://wiki.commonjs.org/wiki/Binary/E
>
> 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 
Uint8Array(origArray.slice(start, end));

     - Vlad



More information about the es-discuss mailing list