[Bug 23682] Fix the current [ArrayClass], [] and sequence<T> mess

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

--- Comment #7 from Jonas Sicking <jonas@sicking.cc> ---
Here's an updated syntax


A) [SameObject] readonly attribute frozen array<MessagePort> ports;
   The 'frozen' modifier indicates that the returned object is frozen before
   it is returned. For now we only need to support it as a modifier for arrays,
   but might be useful for returned dictionaries in the future.

B) readonly attribute frozen array<Gamepad> gamepads;
   Same as A, but can return new objects for different times the getter is
   invoked.

C) readonly attribute NodeList childNodes;
   I.e. simply return a DOM object and use prose to describe any special
   behavior.

D) attribute array<File> files;
   Not sure if this should be iterable<> rather than array<>. The attribute
   always returns an Array, but can be set to any iterable.

E) createIndex(..., iterable<DOMString> key, ...);
   (somewhat simplified as createIndex accepts both a sequence or a single
   value)
   Here 'iterable<>' is used rather than 'array<>' to indicate that any
   iterable object is accepted. Including any 'array<>' or 'frozen array<>'
   value.

F) array<ClientRect> getClientRects();
   or
   frozen array<ClientRect> getClientRects();

   The former syntax would likely mostly be used with [NewObject].

   The latter syntax is likely what you want to use when [SameObject] is used,
   or when the function generally isn't always creating a new object every
   time it is called.


So array<> is intended for return values, but both return values from getters
as well as functions.

iterable<> is intended for arguments to functions that can take iterable
object. Including Array or Map objects. *Possibly* it's also appropriate to use
iterable<> for attributes with setters.

Another thing that we might want to add is an extended attribute which
indicates what to do if an iterable<> argument contains entries that are not of
the intended type. Should such entries be ignored or cause an exception to be
thrown. Or should they be treated as null (hopefully that's never useful).

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

Received on Thursday, 23 January 2014 00:46:29 UTC