- From: Charles Pritchard <chuck@jumis.com>
- Date: Fri, 16 Mar 2012 15:48:27 -0700
On 3/16/2012 3:26 PM, Glenn Maynard wrote: > On Fri, Mar 16, 2012 at 4:44 PM, Charles Pritchard <chuck at jumis.com > <mailto:chuck at jumis.com>> wrote: > > The DataView set of methods already does this work. The raw arrays > are supposed to have platform endianness. > > > That's wrong. This is web API design 101; everyone should know better > than this by now. Exposing platform endianness is setting the > platform up for massive incompatibilities down the road. I make mistakes all the time with UTF8 and raw string arrays. I make mistakes all the time with endianness. Low level API design 101; everyone working with low level APIs makes mistakes. > In reality, the spec is moot here: if anyone does implement typed > arrays on a production big-endian system, they're going to make these > views little-endian, because doing otherwise would break countless > applications, essentially all of which are tested only on > little-endian systems. Web compatibility is a top priority to browser > implementations. It's up to programmers to code defensively. More-so with multi-platform multi-vendor deployments than walled gardens. Authors should be using the spec as written, it only takes one target system to use big-endian. It doesn't harm anything for a vendor to implement as little-endian, as most authors assume and test on little endian. It may cause some harm to alter the spec so as to remove the requirement that coders account for both. > > (DataView isn't relevant here; it's used for different access > patterns. To access arrays of data embedded in an ArrayBuffer, you > use views, not DataView. Use DataView if you have a packed data > structure with variable-size fields, such as the metadata in a ZIP > local file header.) I use the subarray pattern frequently. DataView is not much different than using subarray. Use DataView when it's easier than ArrayBufferView and available.
Received on Friday, 16 March 2012 15:48:27 UTC