typed array strawman proposal
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