Closed
Bug 923919
Opened 11 years ago
Closed 8 years ago
Add support for DOMString[] attributes in webidl
Categories
(Core :: DOM: Core & HTML, defect)
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.
Comment 1•11 years ago
|
||
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?
Reporter | ||
Comment 2•11 years ago
|
||
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.
Comment 3•11 years ago
|
||
A getReceipts method would make a lot more sense, yes!
Who would be familiar with the bluetooth API?
Flags: needinfo?(jonas)
Reporter | ||
Comment 4•11 years ago
|
||
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)
Comment 6•11 years ago
|
||
What's wrong with [ArrayClass]?
Comment 7•11 years ago
|
||
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.
Comment 8•8 years ago
|
||
IDL arrays don't exist in the IDL spec anymore.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•