typed array strawman proposal

Peter van der Zee ecma at qfox.nl
Wed Jan 27 08:16:41 PST 2010

Rather than an arbitrary subset of sizes (Int32Array, etc) I would rather see
some kind of generic ArrayMapping or ArrayVector that takes another array and
the size of each cell (position of the array) in bits as an argument.

new ArrayMapping(arrBuf, intBits, intStart, intFinish);

That way you're not imposing whatever specific need you have right now (in terms
of cell size) on anyone that would have a slightly different need for the same

I don't suppose the fact has to be pointed out that this is already perfectly
possible to do? Create a map or vector on an array and use bitwise operators to
get whatever size you desire? I'm not sure whether the WebGL group is asking for
a new feature, or just something that would be faster than the aforementioned

To be honest, I'm wouldn't really mind a ByteArray kind of object (even don't
really care about the name), but I do oppose some kind of strict typing. It
doesn't seem to fit the language...


> 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.
> Michael
> -----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.
> 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.
> 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
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list