ES6 draft, Rev20 is now available
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequence<T> behaves in IDL. (It uses array-likes.) :/
Anne van Kesteren wrote:
This is different from how sequence<T> behaves in IDL. (It uses array-likes.) :/
This is more general, since array-likes should be iterable to be like arrays, which are iterable.
So this seems ok. Right?
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich <brendan at mozilla.com> wrote:
This is more general, since array-likes should be iterable to be like arrays, which are iterable.
So this seems ok. Right?
An array-like only "length" and properties "0", "1", ... as far as I know. I thought iterable meant they implement the iterator protocol.
Anne van Kesteren wrote:
An array-like only "length" and properties "0", "1", ... as far as I know. I thought iterable meant they implement the iterator protocol.
The meaning of array-like is evolving, maybe. I know, this means old array-likes don't iterate without work. Temporary migration problem?
On 10/30/13 7:57 AM, Anne van Kesteren wrote:
This is different from how sequence<T> behaves in IDL. (It uses array-likes.) :/
We could change that if we change all DOM arraylikes to be iterables (which they already are, I suspect).
The biggest compat issue will be cases that pass { "length": 1, 0: "x" } to a sequence<DOMString> or something, but do people do this in practice?
This is promoting a fix in the Object.prototype ... and since I believe
those dark days where Object.prototype shouldn't be touched due for/in
loops, I like it ^_^
Or maybe it's just a matter of Arguments.prototype , the most common non
iterable always converted via slice?
- are gone
On Oct 30, 2013, at 10:51 AM, Boris Zbarsky wrote:
We could change that if we change all DOM arraylikesto be iterables (which they already are, I suspect).
All that is needed is to add an @@iterator method whose definition is identical to people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values ArrayIterator objects (people.mozilla.org/~jorendorff/es6-draft.html#sec-array-iterator-object-structure ) will work fine with any Array-like objects. But note that ES6 Rev20 has simplified them from what is shown at this link.
The biggest compat issue will be cases that pass
{ "length": 1, 0: "x" }to a sequence<DOMString> or something, but do people do this in practice?
Those are the sort of objects, that we decided to explicitly exclude from spread and for-of. We could wrap an ArrayIterator around any object in those contexts that didn't have a @@iterator. But that would mean that all objects would default to array-like iteration in those contexts. When we discussed this we decided it is more likely that attempting to spreading or iterating over a object without a @@iterator is indication of a program bug. So we throw on it.
For something like { "length": 1, 0: "x" }, one way to make it iterable would be { "length": 1, 0: "x" , [Symbol.iterator]: [].values}}
On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
All that is needed is to add an @@iterator method whose definition is identical to people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values
Right. Pretty sure Gecko already ships just that (with a hack where we use an actual property named "@@iterator", because we don't have internal symbols in SpiderMonkey yet) for WebIDL bindings with an indexed getter.
The biggest compat issue will be cases that pass { "length": 1, 0: "x" } to a sequence<DOMString> or something, but do people do this in practice?
Those are the sort of objects, that we decided to explicitly exclude from spread and for-of.
Sure. The question is whether we can compatibly exclude them from sequence<T> in WebIDL. I expect we can.
Anne, do you want to post to public-script-coord about this, or should I?
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
Those are the sort of objects, that we decided to explicitly exclude from spread and for-of.
Sure. The question is whether we can compatibly exclude them from sequence<T> in WebIDL. I expect we can.
Anne, do you want to post to public-script-coord about this, or should I?
www.w3.org/Bugs/Public/show_bug.cgi?id=23683
(I mostly asked here first since the other breaking changes to IDL to align with JavaScript haven't been very popular. But maybe this is indeed small enough to get away with.)
On Oct 30, 2013, at 12:09 PM, Anne van Kesteren wrote:
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
On 10/30/13 2:28 PM, Allen Wirfs-Brock wrote:
Those are the sort of objects, that we decided to explicitly exclude from spread and for-of.
Sure. The question is whether we can compatibly exclude them from sequence<T> in WebIDL. I expect we can.
Anne, do you want to post to public-script-coord about this, or should I?
www.w3.org/Bugs/Public/show_bug.cgi?id=23683
(I mostly asked here first since the other breaking changes to IDL to align with JavaScript haven't been very popular. But maybe this is indeed small enough to get away with.)
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.
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, rather than JavaScript-wide.
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, 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.
On 10/30/13 3:23 PM, Allen Wirfs-Brock wrote:
If an API is going to return a sequence<T> to JS code
Then it becomes a JS Array object in JS. So there is no change here.
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.
Sequences always use those semantics, since the first thing they do, in the IDL layer before entering the actual API implementation, is make a copy of the list. See dev.w3.org/2006/webapi/WebIDL/#es
On Wed, Oct 30, 2013 at 7:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
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.
That is not the problem.
The problem is that when designing ES it seems like you are not considering the web ecosystem that exists around ES and how that might need to adapt to changes in the underlying language. Or in other words, the language does not exist in a vacuum, yet it feels like you are designing it in that way.
This may very well be a perception and communication problem and I think we are making progress towards addressing it, but please keep that in mind.
At: harmony:specification_drafts The HtML version isn't ready yet, but should be available soon.
Changes include: