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. -- http://annevankesteren.nl/ _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
