Re: Adoption of the Typed Array Specification

On Thu, May 13, 2010 at 5:43 PM, Vladimir Vukicevic <vladimir@mozilla.com>wrote:

> Ah right -- sorry, I keep thinking in terms of ES4.  A sealed object
> certainly makes sense, though it also means that other named properties
> can't be attached... this was brought up as a desired thing,
>

No problem:

    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
        });
      }
      Object.defineProperty(result, 'length', {value: size});
      return result;
    }




> though I would be quite happy to just have them be sealed.  Anyways,
> certainly something that should be discussed... the spec as written was
> using an odd mix of Web IDL and other language because we weren't sure where
> or how it would land.  This is where I think the input of the ES group would
> be very welcome -- I don't think we have the ES language knowledge to really
> define this in terms of how it could look as an ES core feature.
>
> However, another consideration is that the WebGL spec isn't ES specific,
> and yet has to depend on typed arrays.  So perhaps we're really talking
> about two different specs: a main typed array spec that uses Web IDL and can
> be implemented generically in any language, as well as a separate spec
> describing ES types that happen to fulfill the requirements of typed arrays.
>
>     - Vlad
>
>
> ----- "Mark S. Miller" <erights@google.com> wrote:
>
> 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
>
>
>


-- 
    Cheers,
    --MarkM