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

Re: Adoption of the Typed Array Specification

From: Chris Marrin <cmarrin@apple.com>
Date: Tue, 18 May 2010 09:12:15 -0700
Cc: Erik Arvidsson <erik.arvidsson@gmail.com>, arun@mozilla.com, public-script-coord@w3.org, es-discuss@mozilla.org
Message-Id: <6FBC8829-9F2A-46AB-A102-7812160157D9@apple.com>
To: Jonas Sicking <jonas@sicking.cc>

On May 18, 2010, at 12:09 AM, Jonas Sicking wrote:

> Resending this now that i'm signed up on the es-discuss list.
> On Thu, May 13, 2010 at 4:57 PM, Erik Arvidsson
> <erik.arvidsson@gmail.com> wrote:
>> I'm surprised no one has said this yet but here goes:
>> ArrayBuffer needs to extend Array. In other words instances of
>> ArrayBuffer needs to also be instances of Array
>> var ab = new ArrayBuffer;
>> assert(ab instanceof ArrayBuffer);
>> assert(ab instanceof Array);
>> You will also need to make sure that all the internal methods are
>> defined. See 8.12 Algorithms for Object Internal Methods of ES5. For
>> example what does it mean to do [[Delete]] on a byte array?
> My biggest beef with ArrayBuffer is that since it can be cast between
> Int8 and Int16, it exposes endianness of the CPU the code is running
> on. I.e. it will be very easy to write code that works on Intel CPUs,
> but not on Motorola 68K CPUs.
> I don't have much faith in that website developers will test the
> endiannness of the CPU they are running on and manually convert,
> rather than cast, if the endianness is "wrong".

In developing TypedArrays, we had endless discussions about the endianness problem. We ended up with the conclusion that there is no practical way to avoid it AND keep a reasonable feature set AND not end up with an extremely complex API. I don't think this will be a problem in practical use. The most common use of TypedArrays will not use ArrayBuffers at all. If programmers start mapping different ranges of an ArrayBuffer to different views, they need to have advanced knowledge and they have to use care. If they choose to "over-map" the same range to different views on purpose, they had better really understand what they are doing. If they do it accidentally, they have made a programming error. If that error results in the wrong data being used due to endianness or some other error, I don't think it matters.

There is the issue of the naive programmer over-mapping and having it work on some machines and not on others. But I think those cases will be rare. I think the danger of that is worth the features that over-mapping provides.

Received on Tuesday, 18 May 2010 16:13:20 UTC

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