W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

RE: Adoption of the Typed Array Specification

From: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
Date: Wed, 19 May 2010 01:32:09 +0000
To: Jonas Sicking <jonas@sicking.cc>, Chris Marrin <cmarrin@apple.com>
CC: "arun@mozilla.com" <arun@mozilla.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>
Message-ID: <90EDC335A511F2479C63F7337D3CE7DB41E02A93@TK5EX14MBXC116.redmond.corp.microsoft.com>
> -----Original Message-----
> On Behalf Of Jonas Sicking
> I'd love to have ArrayBuffers be a native part of
> Javascript and be to binary data what js strings are to text. I.e. something
> returned any time someone wanted to represent in-memory binary data. But it's
> unfortunate if that data type has these properties.

Endian issues are inherent in at least two situations:
1) allowing multiple-sized accesses (any of byte, 16-bit int, 32-bit int, etc.) to common underlying  byte addressable memory
2) moving byte-streams that encode multi-byte integers from one endian domain to the other.

If you have byte addressable data and allow either of these things then it is possible to run into endian issues.  Fortunately,  you can usually wrap the raw data with abstractions that don't expose the problems.  But the rope is going to be there  if you have this basic functionality.  Personally, I think the functionality is valuable enough to justify itself, even if it means that some programmer may get in trouble with it.

Received on Wednesday, 19 May 2010 01:40:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC