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.


Is a summary of these discussions, and the structure of tradeoffs they
reveal, written down anywhere? Can they be? These non-portable endianness
problems are very non-JavaScript-y. If you are asking us to accept these
problems into JavaScript, we need more than a summary of your conclusions.
We need to understand why seemingly more pleasant options were not. And we
need to go over these tradeoffs ourselves. We might have a different
weighting, and so make different choices.



> 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.
>
> -----
> ~Chris
> cmarrin@apple.com
>
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM