850159 - Support double[] attributes

Status: RESOLVED INVALID

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

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Gamepad uses this; I get a

TypeError: Don't know how to declare return value for DoubleArray

from getRetvalDeclarationForType.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does it mean to use double[], or should that be a sequence<double>?

Can you link to the spec, please?

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html#gamepad-interface

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  So apart from needing to specify that the IDL array is readonly this is actually a sane spec.

We should probably implement limited IDL array support...

Comment 4

[Nathan Froyd [:froydnj]]

Spec mentions readonly-ness now. :)

For primitive types, is it worthwhile to reflect them as typed arrays that share a block of memory with some underlying nsTArray-ish thing?  Can appropriate flags on the typed array be set to prevent members being modified and such?  Pretty sure that approach isn't going to work for mutable arrays, though (.length = ... would get problematic, there are probably other things that I'm missing too).

For more complicated cases, I don't see a good way of implementing this short of doing something like Ms2ger's mentioned plan with nsIVariant, which sounded pretty ugly.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> Spec mentions readonly-ness now. :)

The spec linked in comment 2 sure doesn't....

> For primitive types, is it worthwhile to reflect them as typed arrays 

Reflect in what sense?

The JS reflection of these objects is fixed per current WebIDL spec, and it's not typed arrays.  The C++ reflection we can obviously control.

> I don't see a good way of implementing this short of doing something like Ms2ger's
> mentioned plan with nsIVariant

That proposal doesn't follow the spec at all.

The way to implement this is pretty clear, generally speaking:

1)  Come up with a new proxy family for this stuff.
2)  Codegen the proxy handlers for whatever IDL arrays are used in our IDL.
3)  Codegen the C++ reflections of these IDL arrays.
4)  Write the glue code to map between the JS and C++ reflections.

Comment 6

[Nathan Froyd [:froydnj]]

(In reply to Boris Zbarsky (:bz) from comment #5)
> The way to implement this is pretty clear, generally speaking:
> 
> 1)  Come up with a new proxy family for this stuff.
> 2)  Codegen the proxy handlers for whatever IDL arrays are used in our IDL.
> 3)  Codegen the C++ reflections of these IDL arrays.
> 4)  Write the glue code to map between the JS and C++ reflections.

Ah, so we're codegenning a subclass of DOMProxyHandler that forwards the appropriate bits to C++?  (I'm starting to see how things work a little more clearly, sorry for being slow.)

Comment 7

[Boris Zbarsky [:bzbarsky]]

This wouldn't be a subclass of DOMProxyHandler, because it needs to be in a different proxy family.  We'd need an equivalent of a DOMProxyHandler shared superclass for all array handlers, then codegen subclasses of that.  But yes, that's the general idea.

Comment 8

[Nathan Froyd [:froydnj]]

I think I understand what needs to happen here well enough to implement (parts of) it.  If you haven't heard anything in a week or two, yell at me in #content.

Comment 9

[Nathan Froyd [:froydnj]]

As mentioned on IRC yesterday, I'm not going to get to this in a timely fashion.

Comment 10

[Boris Zbarsky [:bzbarsky]]

IDL arrays are not a thing anymore