Re: ES6 draft, Rev20 is now available
On Wed, Oct 30, 2013 at 7:52 PM, Allen Wirfs-Brock al...@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. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/ -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
Anne van Kesteren wrote: OnTue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Spread now requires an Iterable rather than an array-like This is different from how sequenceT 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? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eich bren...@mozilla.com wrote: Anne van Kesteren wrote: This is different from how sequenceT 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? An array-like only length and properties 0, 1, ... as far as I know. I thought iterable meant they implement the iterator protocol. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com wrote: Anne van Kesteren wrote: This is different from how sequenceT 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? 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? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On 10/30/13 7:57 AM, Anne van Kesteren wrote:
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequenceT behaves in IDL. (It uses array-likes.) :/
We could change that if we change all DOM arraylikesto be iterables
(which they already are, I suspect).
The biggest compat issue will be cases that pass { length: 1, 0: x }
to a sequenceDOMString or something, but do people do this in practice?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
* are gone On Wed, Oct 30, 2013 at 11:00 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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? On Wed, Oct 30, 2013 at 10:26 AM, Brendan Eich bren...@mozilla.comwrote: Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 5:14 PM, Brendan Eichbren...@mozilla.com wrote: Anne van Kesteren wrote: This is different from how sequenceT 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? 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? /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On Oct 30, 2013, at 10:51 AM, Boris Zbarsky wrote:
On 10/30/13 7:57 AM, Anne van Kesteren wrote:
On Tue, Oct 29, 2013 at 4:50 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Spread now requires an Iterable rather than an array-like
This is different from how sequenceT behaves in IDL. (It uses
array-likes.) :/
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
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.values
ArrayIterator objects
(http://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
sequenceDOMString 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}}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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
http://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 sequenceDOMString 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
sequenceT in WebIDL. I expect we can.
Anne, do you want to post to public-script-coord about this, or should I?
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@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 sequenceT in WebIDL. I expect we can. Anne, do you want to post to public-script-coord about this, or should I? https://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.) -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
On Oct 30, 2013, at 12:09 PM, Anne van Kesteren wrote: On Wed, Oct 30, 2013 at 7:01 PM, Boris Zbarsky bzbar...@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 sequenceT in WebIDL. I expect we can. Anne, do you want to post to public-script-coord about this, or should I? https://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 sequenceT 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 sequenceT 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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 draft, Rev20 is now available
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 sequenceT 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 sequenceT 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 sequenceT. 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
Re: ES6 draft, Rev20 is now available
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 sequenceT 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 sequenceT 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 sequenceT. 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 sequenceT 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 sequenceT 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 sequenceT or arraylikeT. 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
Re: ES6 draft, Rev20 is now available
On 10/30/13 3:23 PM, Allen Wirfs-Brock wrote: If an API is going to return a sequenceT 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 sequenceT 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 http://dev.w3.org/2006/webapi/WebIDL/#es-sequence -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ES6 draft, Rev20 is now available
At: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts The HtML version isn't ready yet, but should be available soon. Changes include: Introduced grammar parameters and eliminated NoIn productions Spread now requires an Iterable rather than an array-like B.1.4, Web browser extensions to RegExp Pattern grammar and semantics Updated RegExp to actually do sticky matching. Updated RegExp to support “u” (unicode) patterns and matching. Defined String @@iterator and String Iterator objects bug fixes in Object.mixin Added support for revokable proxies Added Proxy and Proxy.revokable factory functions Removed the JSON grammar and replaced it with references to Ecma-404 Added requirement that Math.random functions in different code realms must produce difference sequences of numbers Made Map, and Set built-in iterators so that once they return a result of completed they always return complete on subsequent calls to next. Added Symbol.prototype[@@toPrimitive] Added name property for functions created via function/generator/class declarations or binding initializers and assignment. Defined the name property conventions for built-in functions. Added normative reference to Ecma-404, removed normative reference to C standard. Added normative reference to Ecma-402 and made Ecma-402 support a conformance requirement for ES implementation that provide an internationalization API. Updated toLocale*String methods with reference Ecma-402 [[Construct]] for Proxy objects throw if no “construct” trap and target does not have a [[Construct]] Changed terminology “ordinary function object” to “ECMAScript function object” fixed ArrayBuffer(len) and %ArrayBuffer%(len) to throw RangeError on infinite length make sure yield is usable as a statement label in non-strict code, except in generator functions. consolidated in BindingIdentifier static semantic restrictions on strict mode declarations of eval and arguments changed the way strict mode use of strict mode only reserved words are specified. use parameterized grammar productions to restrict where return statements can appear added grammar restrictions preventing an ExpressionStatement from stating as “let [” terminology: “internal data property” is now “internal slot” changed handling of non-object values in WeakMap as per bug 1938 Renamed abstract operation CreateOwnDataProperty to CreateDataProperty. Added CreateDataPropertyOrThrow abstract operation Elaborated in 9.3 that built-in functions can be implemented as either ECMAScript functions or as implementation defined exotic functions. Eliminated [[GlobalArray]] compatibility hack in slice and certain Array methods, replaced with a Realm check fixed bugs: 2077-2072, 2069, 2067-2054, 2052-2050, 2048-2046, 2043, 2041-2040, 2037-2035, 2033, 2032, 2030-2028, 2026-2012, 2010-1941, 1938, 1909, 1903, 1900, 1870, 1869, 1863, 1858, 1855, 1854, 1852, 1804, 1660, 1619, 1358, 1287, 1274, 1268, 1250, 1226, 1116, 1113, 972, 872, 791, 749, 740, 625, 594, 528, 526-524, 498, 481, 428, 407, 364, 230, 206, 119 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
