- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 11 Apr 2012 14:04:22 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: Glenn Maynard <glenn@zewt.org>, public-webapps <public-webapps@w3.org>
On 4/11/2012 1:49 PM, Boris Zbarsky wrote: > On 4/11/12 4:40 PM, Charles Pritchard wrote: >>> That argues for the removal of the ArrayBuffer overload, indeed, and >>> just leaving the ArrayBufferView version. >> >> I've got no idea where TC39 is taking things. > > ArrayBuffer and ArrayBufferView and such are not specced in TC39 at > the moment, and I'm not aware of plans to change that (though there > are other plans like Binary Data that are related). > >> I think that's the bigger issue here. > > How so? > >> If ArrayBufferView becomes a JS semantic, some of this is moot > > Which part? When/if we start using the "Binary Data" instead of re-purposing typed arrays. > All of the postMessage semantics use ArrayBuffer AFAIK. > > postMessage does arbitrary object graphs, which can include either > ArrayBuffers or ArrayBufferViews. If you try to postMessage a typed > array, the receiver will get a typed array, as expected. My understanding is/was that an ArrayBufferView will be copied whereas an ArrayBuffer will be neutered/transferred. > >> I know you've been circling this issue for awhile, so I'll put it out >> there again: yes, using typed arrays is difficult. > > Sure, but we shouldn't make it _more_ difficult if we can avoid it. These practices are already established. You're exploring ways to make using them easier. Typed Arrays have matured. They're available in all major implementations and as far as I'm aware, compatible across the implementations. I know they can be a pain in the ass, but they are functioning. -Charles
Received on Wednesday, 11 April 2012 21:04:43 UTC