W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

[Bug 23369] Provide hooks for Typed Arrays

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Sep 2013 18:29:15 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-5E9mHUKmoZ@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

Allen Wirfs-Brock <allen@wirfs-brock.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allen@wirfs-brock.com

--- Comment #6 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Anne from comment #4)
> So I think we should go with APIs accepting /TypedArray/ Objects,
> ArrayBuffer Objects, and DataView Objects, in terms of ES6. If we introduce
> these as IDL types as suggested in comment 1, I suppose we could produce a
> typedef as follows:
> 
> typedef (Int8Array or Uint8Array or Uint8ClampedArray or Int16Array or
> Uint16Array or Int32Array or Uint32Array or Float32Array or Float64Array or
> ArrayBuffer or DataView) ByteSequence;

But this would unnecessarily preclude ES6 subclasses of any of those named
typed array constructors.

The replacement for ArrayBufferView is the function ArrayBuffer.isView(obj)
which tests where its argument is an object that has an ArrayBuffer as its
backing store.

It seems to me, that what you really want to say (in prose) for that typedef is
any object for which ArrayBuffer.isView(object) is true.

Also, need to keep in mind that such view objects may only be viewing a
subsequence of bytes in an ArrayBuffer.  If an API is going to accept both
views and ArrayBuffers it needs to be able to map a view to the appropriate
subsequence of its buffer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 26 September 2013 18:29:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC