On Oct 30, 2013, at 12:29 PM, Anne van Kesteren wrote: > On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock > <al...@wirfs-brock.com> wrote: >> Doesn't really depend upon the usage. If an API is going to return a >> sequence<T> to JS code, it really should have an @@iterator. But that is >> presumably a non-breaking change, from the JS perspective. If an API wants >> to accept a sequence<T> it only needs it to have an @@iterator if it is >> actually going to use JS iterator semantics to process. There is no reason >> that an implementation of such a consuming API couldn't do its own fall back >> to non-iterator based iteration. That would be a non-breaking solution. > > This is about the accepting side, not returning. The idea was for that > was to be the same as the spread operator. Of course we could do > something else and have it compatible with current IDL semantics, but > that's not very coherent, nor desirable long term. So either the > spread operator changes or we change sequence<T>. Going forward it'd > be great if we tried to reason about these things platform-wide, > rather than JavaScript-wide.
I don't understand what is special about the web APIs in this regard. On the accepting side in ES we generally allow no breaking changes. Wherever there was an existing API that accepted old-style "array likes" we now first test for @@iterator and then fall back to the legacy behavior. If there are web APIs that currently accept "array-likes" and you don't do this then you are really to accept a lower bar for backward compatibility than what TC39 has been willing to accept. I really don't see why sequence<T> should be an issue here. It's just part of a specification language and if you are going to have it, it needs to deal with reality. If you currently have APIs that use sequence<T> to accept array-like arguments, those API should continue to accept array-like arguments, regardless of changes you make to WebIDL. Maybe that means that specifications need to change to using a Union of sequence<T> or arraylike<T>. But that's just one solution and really just a meta issue. It doesn't change the legacy that has been implemented and that needs to continue to work. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
