[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #45 from Cameron McCormack <cam@mcc.id.au> ---
(In reply to Domenic Denicola from comment #44)
> Getting down to the business of solving this bug:
> 
> As I see it we have two choices. One, be consistent with sequence<>:
> 
> func(sequence<any> x); // copies the iterable into an array
> func(ArrayBuffer x); // copies the ArrayBuffer into another ArrayBuffer
> 
> func([NoCopy] sequence<any> x); // no copying; spec author must be cautious
> func([NoCopy] ArrayBuffer x); // no copying; spec author must be cautious
> 
> Or two, be inconsistent, but efficient-by-default:
> 
> func(sequence<any> x); // copies
> func(ArrayBuffer x); // no copying
> 
> func([NoCopy] sequence<any> x); // no copying
> func([Copy] ArrayBuffer x); // copies
> 
> The third alternative is to try to retroactively change the meaning of
> sequence<> to require a [Copy] when it must be copied, but I have a hard
> time seeing that as feasible.
> 
> In all cases, we will want to write up a good explanation and guidance
> document explaining the various concerns; in particular we'd need to give
> concrete guidelines on how to use non-copied objects without causing
> undefined behavior or other horrible things.

I don't really like "[NoCopy] sequence<>".  If we want to allow references to
Array objects then we should add a new type "Array" which means that.

Do we need to solve the copying-or-not in the IDL syntax?

Here's my proposal:

* stick with sequence<> meaning "generate a new copy of the iterable thing
passed in"

* introduce types named ArrayBuffer, DataView, and all of the typed arrays
Int8Array, Uint8Array, etc., which all mean "reference to an instance of that
class (or a subclass)"

* pre-define

    typedef (Int8Array or Uint8Array or ... or DataView) ArrayBufferView;

* pre-define

    typedef (ArrayBufferView or ArrayBuffer) BufferSource;

  and make ArrayBuffer distinguishable from all the ArrayBufferView types,
  using [[TypedArrayName]], [[ViewedArrayBuffer]] and [[ArrayBufferData]]
  checks to implement the distinguishability needed in the overload resolution
  algorithm and union type conversion algorithm

* suggest spec writers to use BufferSource as the type when they want to
  receive a chunk of data

* suggest spec writers to return an ArrayBuffer object when generating a
  chunk of data (though I'm convinced about this -- what about for cases
  where we know the author will be interested in inspecting the bytes, not
  just passing the buffer around as an opaque thing?)

* get rid of the ArrayBufferData typedef I recently added in lieu of
  BufferSource

* add a term that means "get a reference to the bytes held by the
  BufferSource" and a term that means "get a copy of the bytes held by the
  BufferSource", both of which work on any of the types in that union;
  the spec author then must be explicit about whether a copy is made
  before getting easy prose access to the bytes (easy access being something a
  bit more high level than generating array index property names and calling
  [[Get]] on the object that came in.)

If the spec author wants to allow plain JS Arrays to be passed in to provide
the data, they can include sequence<octet> themselves.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 3 October 2014 06:19:24 UTC