- From: <bugzilla@jessica.w3.org>
- Date: Sun, 28 Sep 2014 21:38:42 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 --- Comment #11 from Jonas Sicking <jonas@sicking.cc> --- I've talked with Dominic over this past week since I'd like to move this forward. Based on those conversations here's what we agreed on. > A) Read-only properties returning read-only arrays which never changes for > the lifetime of the array. Example: MessageEvent.ports This should return a frozen JS Array. The same array instance will be returned every time the property is gotten (i.e. we can mark it with [SameObject]). > B) Read-only properties returning read-only arrays which on occasion the > platform needs to change, but which the website should not be able to > change. Example: Navigator.gamepads This should return a frozen JS Array. However it will not always return the same Array instance. Instead a new Array instance will be created every time that the list of gamepads change, which should only happen off of a separate task or in response to some explicit DOM API. So the below test should always return true. navigator.gamepads === navigator.gamepads; > C) Read-only properties and functions returning "live" arrays defined in > existing APIs which on occasion the platform needs to change, but which the > website must not be able to change. Example: Node.childNodes, Window.frames For these we should use [ArrayClass]. However since this will only be useful for "live" arrays, and "live" arrays are generally not liked by authors as well as hard to implement, we should only use it for legacy APIs. Thus we should rename it to "[LegacyArrayClass]". As has been previously discussed, we can't use [ArrayClass]/[LegacyArrayClass] on HTMLCollection since it has an unbounded set of property names. But we can use it for NodeList. > D) Mutable properties returning arrays that both the website and the > platform is able to change. Examples: HTMLInputElement.files This one is complicated. I'll post separately about this. > E) Functions accepting an array-like thing as an argument. Example: > IDBObjectStore.createIndex() This should simply take an iterable object. > F) Functions returning an array-like thing as a result. Example: > Element.getClientRects() These should always return a freshly created JS Array instance. This array should not be frozen. I.e. we can mark any functions like this with [NewObject]. There are to my knowledge no functions in the DOM today that sometimes return the same array-like object instance. For example based on the values of the arguments passed to the function or based on other state. The only exception to this is functions that return "live" arrays-like objects and so are covered by C above. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Sunday, 28 September 2014 21:38:46 UTC