W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

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

From: <bugzilla@jessica.w3.org>
Date: Sun, 28 Sep 2014 21:38:42 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23682-3890-jZnE5Sx2vU@http.www.w3.org/Bugs/Public/>

--- 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC