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

Re: Adoption of the Typed Array Specification

From: Vladimir Vukicevic <vladimir@mozilla.com>
Date: Thu, 13 May 2010 17:43:52 -0700 (PDT)
To: "Mark S. Miller" <erights@google.com>
Cc: Erik Arvidsson <erik.arvidsson@gmail.com>, arun@mozilla.com, public-script-coord@w3.org, es-discuss@mozilla.org
Message-ID: <190661110.184584.1273797832272.JavaMail.root@cm-mail03.mozilla.org>
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, 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++) { 

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 

es-discuss mailing list 

es-discuss mailing list 

Received on Friday, 14 May 2010 00:44:57 UTC

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