typed array strawman proposal

Brendan Eich brendan at mozilla.com
Wed Jan 27 09:17:37 PST 2010

On Jan 27, 2010, at 8:16 AM, Peter van der Zee wrote:

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

The WebGL use-case cannot tolerate scaling by a variable "intBits"  
element width. It wants constant (compile-time) element size.

Moreover, what you propose is strictly less usable than common machine- 
typed views of byte vectors. So if something like the above were the  
only API, there would soon be a set of standard wrappers. Let's avoid  
requiring that wheel to be reinvented in the ecosystem.

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

No, JS Arrays are not usable as is. Besides all the problems with  
prototypes, extensibility, .length mutability, and holes (holes really  
do make it hard to optimize), JS Arrays hold values, values include  
numbers, and numbers are (or appear to be) IEEE754 double precision  
floating point.

Making JS users write bitwise ops to force things back to int32 or  
uint32 (or narrower) does not address the common float (32-bit) case  
in graphics hardware and *GL libraries. It also requires great care  
and effort on the part of programmers -- and then the optimizing JS  
engine implementers have to pattern-match on all the bitwise ops to  
make it efficient.

But even if that mistaken path were taken, and the bulk of users taxed  
heavily along with implementors, and ignoring holes and other  
problems, the semantics of doubles remain. That is, if someone fails  
to use the right bitwise clamping, they should be able to read and  
write doubles. This too is not tolerable when dealing with graphics  


More information about the es-discuss mailing list