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

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

From: <bugzilla@jessica.w3.org>
Date: Sun, 05 Oct 2014 05:45:04 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23682-3890-zajKztTo2o@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

--- Comment #25 from Cameron McCormack <cam@mcc.id.au> ---
While there's no perfect solution here, I think the use of frozen arrays
probably gives us the most consistent and simple solution.  I think it's worth
giving it a shot.

For the syntax, I think we should avoid trying to make sequence<> be more like
an object reference type.  Let's stick with it meaning a copy-by-value sequence
of values.

So I think we can basically do all this just by adding a new FrozenArray<T>
type, not distinguishable from sequences, which represents references to frozen
array objects, and which converts JS values just like sequence<T> does now
(i.e., it takes an iterable) but then does the IDL -> JS conversion to get an
Array object and then freezes it.

For the different cases:

A)

interface MessageEvent : Event {
  ...
  [SameObject] readonly attribute FrozenArray<MessagePort>? ports;
};

The [SameObject] doesn't buy us a lot here, but we can use it.

B)

partial interface Navigator {
  readonly attribute FrozenArray<Gamepad> gamepads;
};

Prose defines when the value of gamepads changes to a newly created frozen
array.

C)

[LegacyArrayClass]
interface NodeList {
  ...
};

If it turns out to be feasible.

D)

interface HTMLInputElement {
  ...
  attribute FrozenArray<File> files;
};

This would throw if any non-File objects were found in the iterable that you
assign.

E)

interface IDBObjectStore {
  ...
  IDBIndex createIndex(DOMString name,
                       (DOMString or sequence<DOMString>) keyPath,
                       optional IDBIndexParameters optionalParameters);
};

No change.

F)

partial interface Element {
  ...
  sequence<DOMRect> getClientRects();
};

No change (well actually this is a DOMRectList at the moment, but the pattern
of using sequence<> for a plain Array return value is unchanged).


The only thing this doesn't cover is an enforcement of say Navigator.gamepads
not changing value in the one script turn.  Management of the Array reference
that gamepads holds is up to that spec.  I guess it's enough to just say "queue
a task to update Navigator.gamepads to value blah."?

I pushed a branch with these changes:

https://github.com/heycam/webidl/compare/arrays

https://rawgit.com/heycam/webidl/arrays/index.html#idl-frozen-array
https://rawgit.com/heycam/webidl/arrays/index.html#es-frozen-array
https://rawgit.com/heycam/webidl/arrays/index.html#dfn-distinguishable
https://rawgit.com/heycam/webidl/arrays/index.html#dfn-overload-resolution-algorithm
https://rawgit.com/heycam/webidl/arrays/index.html#es-union

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Sunday, 5 October 2014 05:45:08 UTC

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