- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 Sep 2013 18:29:15 +0000
- To: public-script-coord@w3.org
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