typed array strawman proposal

Brendan Eich brendan at mozilla.com
Wed Jan 27 08:25:14 PST 2010

On Jan 27, 2010, at 12:20 AM, Michael Daumling wrote:

> 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?

The WebGL group has aimed at the latter design. However, they've used  
the "Array" name. I agree it's not ideal given the JS meaning of  
"Array", which is much more complicated (properties with arbitrary  
string-equated names, extensible .length, truncation via .length,  
prototype-based delegation, holes which can be "seen through", the  
list goes on).

"Buffer" is a better name, so perhaps ByteBuffer would be best, but  
then the Int32Array, etc. names do not refer to the buffer-type name- 
part "Array". One could imagine Int32Vector : VectorBuffer but the  
latter seems redundant or incorrect (not a buffer of vectors, not a  
vector of buffers). But let's not get hung up on names, yet, if the  
semantics need attention.

Apart from the name, the indexing notation and .length seem  
unassailable, even though .length is fixed.

So naming aside, what you ask for seems like what the WebGL group have  
specified: efficient wrappers for native arrays.


More information about the es-discuss mailing list