ES6 draft, Rev20 is now available
allen at wirfs-brock.com
Wed Oct 30 12:52:01 PDT 2013
On Oct 30, 2013, at 12:29 PM, Anne van Kesteren wrote:
> On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
> <allen at 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,
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.
More information about the es-discuss