Closed Bug 923919 Opened 11 years ago Closed 8 years ago

Add support for DOMString[] attributes in webidl

Categories

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

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: fabrice, Unassigned)

References

Details

codegen.py fails with "TypeError: Don't know how to declare return value for StringArray". The current workaround used in a few places (BluetoothDevice.webidl and BluetoothAdapter.webidl) is to use an 'any' type instead of DOMString[] for attributes. We would also need that for the 'receipts' property in the mozApps api.
So what behavior do you actually want from these attributes? Where is the spec that describes their behavior? We currently have no plans to implement IDL arrays as currently specified, because pretty much everyone agrees that that's not the direction the platform plans to go in. So I would like to understand the desired API for BluetoothDevice, say, before deciding how to implement it. It looks like the current behavior is: 1) Getting .uuids always hands out the same JS Array object. 2) Modifications to this object are visible to later getters of the object. In particular, you can add non-strings in there. 3) Modifications to that object have no effect whatsoever on the C++ code. Is that correct? Is that the intended behavior that is intended to get standardized at the W3C?
Blocks: 851726
Peter just told me that arrays are going away from webidl, so I'm closing as WONTFIX. For the mozApps API I can move to a getReceipts() method instead of the readonly attribute. I'm not familiar with the bluetooth api so I can't answer for the bluetooth api needs.
A getReceipts method would make a lot more sense, yes! Who would be familiar with the bluetooth API?
Flags: needinfo?(jonas)
cc ing Eric which owns Bluetooth.
Anne is a better person to talk to about arrays in APIs. We keep being bit by the lack of proper solutions for using arrays and keep coming up with crappy workarounds in the form of NodeList, FileList, functions-instead-of-properties etc. We need to either hound TC39 until they provide some good answers, or simply get one of our JS hackers to come up with some good proposals and implement those.
Flags: needinfo?(jonas)
What's wrong with [ArrayClass]?
http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0667.html was the plan Domenic and I had, but it seems some people have some reservations. Trying to get them to pay attention is hard. [ArrayClass] just puts Array on the prototype so you'd still have to define custom objects all the time.
IDL arrays don't exist in the IDL spec 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.