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

Re: Adoption of the Typed Array Specification

From: Mark S. Miller <erights@google.com>
Date: Thu, 13 May 2010 17:34:43 -0700
Message-ID: <AANLkTik8PJ0sxv1J0QAE8iybWSuQoyfdoYXGRsSj2E1w@mail.gmail.com>
To: Vladimir Vukicevic <vladimir@mozilla.com>
Cc: Erik Arvidsson <erik.arvidsson@gmail.com>, arun@mozilla.com, public-script-coord@w3.org, es-discuss@mozilla.org
On Thu, May 13, 2010 at 5:15 PM, Vladimir Vukicevic <vladimir@mozilla.com>wrote:

> This is difficult to do, given the goals of typed arrays -- they wouldn't
> behave like normal Arrays in most meaningful ways.  At the core, an
> ArrayBuffer is of fixed size, and it doesn't make sense to index an
> ArrayBuffer directly (because there's no indication of what format the data
> should be accessed in).  Making the array view types instances of Array
> might work, but again given that they're fixed length, there's a significant
> difference there.
>

in ES5:

    var x = [];
    for (var i = 0; i < N; i++) {
        x.push(0);
    }
    Object.seal(x);

The x that results from the above code is fully populated, of fixed length,
and must remain fully populated. It is much closer to what programmers
coming from other languages might regard as an array.

UInt8Array can even be described as

    function UInt8Array(size) {
      const result = [];
      for (let i = 0; i < size; i++) {
        let value = 0; // Relies on ES-Harmony block level scoping of "let"
        Object.defineProperty(result, i, {
          get: function() { return value; },
          set: function(newValue) {
            if (notUInt8(newValue)) { throw new TypeError("oops"); }
            value = newValue;
          },
          enumerable: true
        }
      }
      return Object.seal(result);
    }

Since the result is simply a constrained array, it still inherits all our
nice shiny higher order methods from Array.prototype.

I am of course not suggesting that it be implemented that way. I'm not sure
I'm even suggesting that it be specified that way. I'm only observing that a
fixed length type-limited array is not necessarily at odds with the concepts
already present in the language.




>
>     - Vlad
>
>
>
> ----- "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?
>
>
> On Thu, May 13, 2010 at 05:57, Arun Ranganathan <arun@mozilla.com> wrote:
> > Greetings, TC-39 WG and script mavens!
> >
> > Browser vendors participating in the WebGL WG intend to implement the
> "Typed
> > Arrays" specification, allowing for greater manipulation of binary data:
> >
> >
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html
> >
> > The draft specification (a work in progress) resides at Khronos, which is
> > typically an unusual home for something integral to the rest of the web
> > platform.  Khronos is where we work on WebGL, which enjoys Google, Opera,
> > Mozilla, and Apple participation, amongst other organizations.
> >
> > The general usefulness of constructs such as ArrayBuffers (covered in the
> > "Typed Arrays" draft specification) lends itself to other web platform
> > specifications, such as the File API, parts of which are implemented in
> > Firefox 3.6.3:
> >
> > http://dev.w3.org/2006/webapi/FileAPI/
> >
> > In the above draft (also a work in progress), the Blob interface exposes
> an
> > ArrayBuffer property, which can then be used with different views.
> >
> > While implementations are currently proceeding unimpeded by
> standards-track
> > considerations, it would be useful if Typed Arrays were taken on as a
> work
> > item by TC-39, for more general inclusion in JavaScript.  Should it live
> > elsewhere, and if so, where?
> >
> > -- A*
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
Received on Friday, 14 May 2010 00:35:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:02 UTC