Re: Adoption of the Typed Array Specification

On Tue, May 18, 2010 at 9:12 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> 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.

This is almost even more unfortunate :)

I.e. the fact that this type-casting isn't even a needed or desired
feature, but rather a side effect of various other tradeoffs. I.e.
we're adding a very unfortunate feature to the language, without even
really wanting the feature itself.

Like Mark I'd love to see the requirements and the discussions that
made you arrive at the current proposal. 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.

/ Jonas

Received on Tuesday, 18 May 2010 17:49:02 UTC