923919 - Add support for DOMString[] attributes in webidl

Status: RESOLVED INVALID

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

Description

[[:fabrice] Fabrice Desré]

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

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[[:fabrice] Fabrice Desré]

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

[Boris Zbarsky [:bzbarsky]]

A getReceipts method would make a lot more sense, yes!

Who would be familiar with the bluetooth API?

Comment 4

[[:fabrice] Fabrice Desré]

cc ing Eric which owns Bluetooth.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 6

[Masatoshi Kimura [:emk]]

What's wrong with [ArrayClass]?

Comment 7

[Anne (:annevk)]

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

[Boris Zbarsky [:bzbarsky]]

IDL arrays don't exist in the IDL spec anymore.