Allow iterable objects without having to become fake arrays (or fix spec)

[tabatkins]

Right now, if you use an iterable<> declaration, you must also "support indexed properties". This requires you to define the set of "supported property indexes", define a "length" attribute, and appears to require you to define an indexed property getter (and presumably an optional setter, if you're not readonly?).

On the other hand, the iterable<> example does none of those - the "SessionManager" just says iterable<Session> and nothing else. The example refers to "values to iterate over", which appears to be a broken link (just links to #).

So does iterable<> automatically make you a fake array, or does it just mean you provide a value iterator?

[bzbarsky]

It used to be that there was a concept of value (as opposed to pair) iterables divorced from indexed properties in the spec.

It was removed because there weren't any use cases and the spec didn't really define its behavior very clearly. Not only that, but there were several possible behaviors it could have defined, and it wasn't clear which one was actually desired. Instead of having untested (and broken) complexity, that bit was removed pending actual use cases that could guide the design. See thread starting at https://lists.w3.org/Archives/Public/public-script-coord/2015OctDec/0039.html

It looks like https://github.com/heycam/webidl/pull/72 didn't update all the parts of the SessionManager example...

Anyway, per current spec you can only use single-type iterable<> on something with indexed properties, but we're generally open to loosening that restriction if there are clear use cases. That requires figuring out exactly which forEach behavior we want, at the very least. Or whether it should be tweakable in the IDL or something...

[tabatkins]

Well, pending Array subclassing, I want to expose the entries in a list-like interface. We've got two of them in TypedOM at the moment - the CSSUnparsedValue class (a list of alternating strings and variable references) and the CSSTransformValue class (a list of transform functions). The bare minimum of useful functionality would be to expose an iterator for these objects; otherwise I'll have to more awkwardly expose a raw Array attribute, and do some funky checking of the values when you push the object back into CSS.

[annevk]

The checking of values can be done by IDL's sequence<>, no?

[tabatkins]

Attributes can't use a sequence<> type. I'd have to be even more ridiculously non-JS and use a get/set function pair.

[domenic]

The checking of values can be done by IDL's sequence<>, no?

Yes.

Attributes can't use a sequence<> type. I'd have to be even more ridiculously non-JS and use a get/set function pair.

I don't know what you mean by this, but that's not correct as stated. Any iterable that authors pass is converted to a sequence<>, with the checking of values done during the conversion.

[tabatkins]

I mean that, per WebIDL, you cannot write attribute sequence<Foo> bar;