742209 - Sort out the typed array reflection situation on the C++ side

Status: RESOLVED DUPLICATE of bug 747827

(Core :: DOM: Core & HTML, defect)

Description

[Boris Zbarsky [:bzbarsky]]

How do we really want to pass them?  Can we specialize to a Foo* + length in a struct in some cases?

Comment 1

[Boris Zbarsky [:bzbarsky]]

Current proposal:


For arguments, we define a struct like so:

  template<typename T>
  struct TypedArray {
    T* const mData;
    const uint32_t mLength;
    JSObject* const mObj;
  };

and typedefs:

  typedef TypedArray<uint8_t> ArrayBuffer;
  typedef TypedArray<uint8_t> ArrayBufferView;

Typed arrays are converted to the corresponding struct of this type, which is then passed to the C++ by reference, with Uint8ClampedAray using T=uint8_t.  ArrayBuffer arguments end up using the ArrayBuffer typedef above; ArrayBufferView use the ArrayBufferView typedef.  Or we may create separate classes for ArrayBuffer and ArrayBufferView if we end up with function overloads that need to take either one of those or a Uint8TypedArray.

In all cases, the mObj will be set to the actual passed-in object.  This will allow consumers that need to store and/or return the object to do so.

An alternative would be to just pass the JSObject* and make sure we have JS APIs which work sanely on those.  If those do happen, would people prefer to do this instead of the struct idea above?  I will admit to still liking the struct thing because it's so explicit....

For return values, I think we'll just use JSObject*.  The typed array _creation_ APIs are pretty straightforward, and if we have to return an array we were given before then a JSObject* is really the best we can do.  An alternative would be to use a TypedArray struct as above, returned by value, and with either mData or mObj but not both non-null.  In that case the binding would create the typed array itself in the mData non-null case.  I'm not sure this is worth it, though.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Whoops.  This happened already...