Closed Bug 850159 Opened 11 years ago Closed 8 years ago

Support double[] attributes

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: Ms2ger, Unassigned)

References

(Blocks 1 open bug)

Details

Gamepad uses this; I get a

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

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

Can you link to the spec, please?
Flags: needinfo?(Ms2ger)
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...
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.
> 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.
(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.)
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.
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.
Assignee: nobody → nfroyd
Blocks: 851542
No longer blocks: 604039
Blocks: 851726
No longer blocks: 851542
As mentioned on IRC yesterday, I'm not going to get to this in a timely fashion.
Assignee: nfroyd → nobody
IDL arrays are not a thing anymore
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.