- From: <bugzilla@jessica.w3.org>
- Date: Thu, 23 Jan 2014 00:46:26 +0000
- To: public-script-coord@w3.org
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 on the CC list for the bug.
Received on Thursday, 23 January 2014 00:46:29 UTC