This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27427 - Consider using iterable<> for DOMRectList
Summary: Consider using iterable<> for DOMRectList
Status: RESOLVED MOVED
Alias: None
Product: FXTF
Classification: Unclassified
Component: Geometry (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: sideshowbarker+geometry
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-25 10:39 UTC by Simon Pieters
Modified: 2018-04-15 18:16 UTC (History)
6 users (show)

See Also:


Attachments

Description Simon Pieters 2014-11-25 10:39:03 UTC
http://dev.w3.org/fxtf/geometry/#DOMRectList

[[
interface DOMRectList {
]]

http://krijnhoetmer.nl/irc-logs/whatwg/20141125#l-217 :

> <annevk> zcorpan: getClientRects() should really use iterable<>

http://heycam.github.io/webidl/#idl-iterable
Comment 1 Simon Pieters 2015-04-19 18:34:45 UTC
I don't know what the correct thing to do is here. DOMRectList has [ArrayClass] in Gecko.
http://mxr.mozilla.org/mozilla-central/source/dom/webidl/DOMRectList.webidl

What is the difference between iterable<> and [ArrayClass]?
Comment 2 Boris Zbarsky 2015-04-19 22:50:33 UTC
[ArrayClass] means that the object's prototype chain terminates in Array.prototype.

iterable<> means that the object's prototype has a property named Symbol.iterator whose value is a function that, when called, returns an object whose behavior then needs to be defined by prose.  It also means that there are functions called "entries", "keys", and "values" defined on the prototype, which also return objects whose behavior needs to be defined by prose.

So they're pretty much totally unrelated, except insofar as Array.prototype has properties named "entries", "keys", "values", and Symbol.iterator that return objects that are iterators over generic arraylikes.

Also, I'm not quite sure what the point of this bug is (though it might have had a point when it was filed; Web IDL has changed some since them).  DOMRectList has an indexed getter, and all objects with an indexed getter are defined to be iterable in Web IDL anyway: their prototype has a property named Symbol.iterator whose value something that will iterate over he indices.  See <http://heycam.github.io/webidl/#es-iterator>.

So the only real change from using iterable<> here would be that we would get entries/keys/values in addition to iterability, and would need to manually define the iteration behavior instead of getting to reuse already-existing ones.
Comment 3 Simon Pieters 2015-04-20 11:45:57 UTC
OK. Thanks.

Anne, please reopen if you think it still makes sense to use iterable<> here.
Comment 4 Anne 2015-04-27 09:19:09 UTC
Using iterable<> would align with DOMTokenList and NodeList. Also, I think you only need to define the underlying collection once.

Does [ArrayClass] maybe also add keys/entries/values these days? They are on the prototype in ES6 so maybe when using [ArrayClass] iterable<> is somewhat redundant?

(Also, it seems more ES6-y to instead mixin the array methods than put it at the end of the prototype chain... But I guess that's a separate bug.)
Comment 5 Boris Zbarsky 2015-04-27 14:16:21 UTC
> Using iterable<> would align with DOMTokenList and NodeList.

Why are those using iterable<>?  What's the goal?

If it's just to get keys/entries/values/forEach... is there a reason we can't just have all things with an indexed getter have them automatically (mixing in the things from Array.prototype, basically, either by value or by reference)?

> Also, I think you only need to define the underlying collection once.

And define the snapshotting behavior, if any, right?  I'd need to check the other bits of the spec to see whether anything else needs to be defined.

> Does [ArrayClass] maybe also add keys/entries/values these days? 

Yes, since they're on Array.prototype.
Comment 6 Anne 2015-04-27 14:19:07 UTC
(In reply to Boris Zbarsky from comment #5)
> If it's just to get keys/entries/values/forEach... is there a reason we
> can't just have all things with an indexed getter have them automatically
> (mixing in the things from Array.prototype, basically, either by value or by
> reference)?

Yeah I guess, unless there's compat concerns? I'm not the IDL editor :-P


> And define the snapshotting behavior, if any, right?

Yes, though per arv I'm not doing any of that. If a list was already live we should just leave it as such.
Comment 7 Boris Zbarsky 2015-04-27 14:23:53 UTC
> Yeah I guess, unless there's compat concerns?

OK.  So the goal here is in fact to get keys/entries/values/forEach on the lists?

I still think ArrayClass is the right way to do that in general; this is _precisely_ why those functions are generic on Array.prototype....  We just need to do the concat-spreadable thing to make it possible to use ArrayClass on NodeList, for example...
Comment 8 Anne 2015-04-27 14:33:22 UTC
I think that is the goal, yes. I'll let Domenic confirm. An ArrayClass mixin variant might be okay? I didn't know we could solve the NodeList case, that sounds rather wonderful.
Comment 9 Domenic Denicola 2015-04-27 14:42:31 UTC
I agree that for interfaces with [ArrayClass] there is no reason to also add iterable<>.

For this case I think [ArrayClass] is still reasonable.

It would be even better if [ArrayClass] mutated into a proper subclass of Array; I don't quite remember the gaps there, but I'd guess they mainly have to do with the custom indexed getter/setter implementations instead of using the exotic behavior of array directly. Which would mean that any such proper subclasses would not have type restrictions and would be read-write.

If we desire to keep readonly-ness or type restrictions then indeed some form of mixin (which only mixes in the non-modifying methods, for example) would make more sense.

---

Another approach: it would be great if APIs never returned a DOMRectList but instead returned a normal array. (As noted in the spec.) However, like many APIs of its type, people might be using item(). For that case we could create a single array subclass with an item() method and have the platform use that whenever necessary.
Comment 10 Boris Zbarsky 2015-04-27 14:47:27 UTC
Yes, I agree that once we have proper subclassing in UAs then having an Array subclass with item() and using it instead of DOMRectList is the way to go.  I thought that was everyone's plan of record...
Comment 11 Domenic Denicola 2015-04-27 14:48:55 UTC
I guess I never remember saying that out loud. But OK :)

Since we have such subclassing support in Chrome and IE technical preview already, it might be time to spec that.
Comment 12 Dirk Schulze 2018-04-15 18:16:21 UTC
The discussion kind of continued here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27428

referenced by https://github.com/w3c/fxtf-drafts/issues/199

It seems like the [ArrayClass] proposal didn't went forward.

I am closing this issue. If there is anything more to discuss continue the discussion on the references issue.