This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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]?
[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.
OK. Thanks. Anne, please reopen if you think it still makes sense to use iterable<> here.
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.)
> 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.
(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.
> 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...
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.
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.
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...
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.
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.