[Bug 21555] Use of IDL arrays for keyPath values is underdefined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21555

--- Comment #10 from Cameron McCormack <cam@mcc.id.au> ---
(In reply to comment #2)
> "This will be either a DOMString, a variable length DOMString array or null.
> If this property returns an array, it returns the same instance on every
> access to the property, and modifications to the array have no affect on the
> object store."
> 
> Is that sufficient?

Let me just ask for a clarification.  When you say "a variable length DOMString
array" does that mean you are fine with it being a "platform array object",
i.e. a host object that behaves a bit like a native Array, but not exactly?  To
be clear, that's what "DOMString[]" means.

Web IDL specifically disallows sequence<T>, which means "a native Array object
whose values are copied out and converted to type T when you pass it in to a
method, and creates a new Array object each time when returned from a method",
from being used as the type of an IDL attribute.  This is exactly to avoid the
issue Boris mentions in comment 1, where you probably don't want to return a
newly created object every time you get the attribute.

So the wording above won't get you anything similar to Gecko's behaviour, and
you can't actually get this behaviour unless you write the type as "any" or
"object" and then in prose describe exactly when native JS Array objects get
created and returned.

My feeling is that using DOMString[] is the better option, since it is less
confusing than returning an Array object that could be modified but which has
no effect.  You could then say in prose that the same object is always returned
from this IDL attribute (you would have the object update itself to reflect the
curreny key path), and you would also declare the object returned as "read
only" http://dev.w3.org/2006/webapi/WebIDL/#dfn-read-only-array.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 3 April 2013 00:09:55 UTC