I thought about yield* but it was not available at the time I wrote this.
But it does not fit the bill because it deals with the synchonous part of
the generator dance, not the async part. My run loop is if a bit more than
the yield* loop (but not much more). The differences are the tests that
I forgot to follow up on this: the issue in Asana was fixed on their side
last week.
We haven't received any other reports of sites these methods are causing
issues for, so it's looking pretty good so far.
On Fri, Jul 5, 2013 at 8:38 PM, Till Schneidereit t...@tillschneidereit.net
wrote:
On Tue, Jul 16, 2013 at 5:39 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
I forgot to follow up on this: the issue in Asana was fixed on their side
last week.
We haven't received any other reports of sites these methods are causing
issues for, so it's looking pretty good so far.
On Jul 15, 2013, at 10:30 PM, Brendan Eich wrote:
Axel Rauschmayer wrote:
The (x === Object(x)) test evaluates to true for value objects in this
proposal, though. This may break code looking for primitives but we need
to see what such code expects. Is it filtering out the legacy
Allen Wirfs-Brock wrote:
On Jul 15, 2013, at 10:30 PM, Brendan Eich wrote:
Axel Rauschmayer wrote:
The (x === Object(x)) test evaluates to true for value objects in this proposal, though. This may break code looking for
primitives but we need to see what such code expects. Is it filtering out
On Jul 16, 2013, at 4:34 AM, Andreas Rossberg wrote:
On 15 July 2013 19:44, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The is primarily an internal spec. change. Many internal operations within
the spec. require objects as parameters. This required inserting inserting
explicit guards
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
This would make generators deep, violating the non-interleaving assumptions
of intermediate callers on the call stack. This is why we accepted
generators only on condition that they be
Mark S. Miller wrote:
On Tue, Jul 16, 2013 at 10:54 AM, Claus Reinke
claus.rei...@talk21.com mailto:claus.rei...@talk21.com wrote:
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
This would make generators deep,
Le 16/07/2013 19:54, Claus Reinke a écrit :
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to use
.forEach instead of for..of.
for..of does what you need here with
This is a resurrection of an earlier proposal from Nathan Wall [1], that
would make Function.length configurable. The initial proposal was to make
it writable, but configurable instead was suggested by Claude Pache [2].
Nathan's original post [1] does a good job of outlining the motivation, so
I
I referenced Function.length instead of Function#length. Here's the
actually relevant spec [1]:
The value of the length property is an integer that indicates the typical
number of arguments expected by the function. However, the language permits
the function to be invoked with some other number
Allen Wirfs-Brock wrote:
We're stuck with numbers, strings, and booleans and their corresponding
wrappers. We don't need more special cases at that level.
I should write an apologator
(http://www-archive.mozilla.org/apology.html) for inflicting primitives
as non-objects in those ten days in
On Tue, 16 Jul 2013, Andy Earnshaw wrote:
navigator.language isn't part of any stable specification
It's part of the HTML standard:
http://whatwg.org/html/#language-preferences
...which is very stable at this point (there's basically no way that part
of the spec can change in an
All of the new constructors, Map, Set, WeakMap and WeakSet should fail
when called as a function unless `this` already has a certain internal
property, ie [[MapData]]. This is so that sub classing works as
expected.
However, all JS engines that supports Map, Set and WeakMap are future
hostile and
On Wed, Jul 10, 2013 at 11:49 PM, Mark S. Miller erig...@google.com wrote:
Hi Jonas,
The perpetual hazard with trying to clean things up is, of course, legacy
compat constraints. Regarding ES itself, many of those on this list
(including myself) feel oriented about when and where these bite
On Tue, Jul 16, 2013 at 7:10 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
All of the new constructors, Map, Set, WeakMap and WeakSet should fail
when called as a function unless `this` already has a certain internal
property, ie [[MapData]]. This is so that sub classing works as
On Tue, Jul 16, 2013 at 3:45 PM, David Bruant bruan...@gmail.com wrote:
Le 16/07/2013 19:54, Claus Reinke a écrit :
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
I have been thinking and with for..of, I can't find a good reason to
Brandon Benvie wrote:
On 7/16/2013 4:10 PM, Erik Arvidsson wrote:
All of the new constructors, Map, Set, WeakMap and WeakSet should fail
when called as a function unless `this` already has a certain internal
property, ie [[MapData]]. This is so that sub classing works as
expected.
However, all
On Tue, Jul 16, 2013 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote:
Object.toString(x)
I assume you mean Object.prototype.toString.call(x)
I *don't* think it's important what this returns. I.e. I would guess
that we can safely subclass DOMException as needed.
I think we have the
Mark S. Miller wrote:
On Tue, Jul 16, 2013 at 4:56 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
More substantive: Mark's suggestion seems better because it throws
on random wrong this but supports strict calls by unqualified name.
Nit: All calls. The
On Jul 16, 2013, at 4:10 PM, Erik Arvidsson wrote:
All of the new constructors, Map, Set, WeakMap and WeakSet should fail
when called as a function unless `this` already has a certain internal
property, ie [[MapData]]. This is so that sub classing works as
expected.
Yes, indeed:
let m
On 7/16/2013 4:56 PM, Brendan Eich wrote:
Mark's suggestion seems better because it throws on random wrong this
but supports strict calls by unqualified name.
I don't think that it'd be nice if `Map()` could throw or not throw
depending on strictness of the caller. Working around that
On 7/16/2013 5:09 PM, Mark S. Miller wrote:
Nit: All calls. The non-coercion of |this| depends only on the
strictness of the callee, not the caller.
Ah yes, right! Nevermind on the complaint in my last message.
___
es-discuss mailing list
I completely agree with you Allen. new-less construct is an anti pattern.
On Tue, Jul 16, 2013 at 5:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I understand that fully supporting @@create requires a lot of work but
until then we should at least throw when called as function to allow
On Jul 16, 2013, at 4:41 PM, Mark S. Miller wrote:
I like the general idea. But when actually called simply as a function, this
would be unpleasant. Understanding that any ES5 behavior will be a compromise
to prepare the ground for ES6, I suggest this variant:
function
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says this should be a TypeError.
It's more consistent with the other members of Object.prototype to do an
implicit ToObject here, and apparently matches existing implementations. Is it
intentional
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says this should be a TypeError.
What is the relevant part of the new spec?
In B.2.2.1, step #2 throws a TypeError instead of doing a ToObject.
get Object.prototype.__proto__
The value of
On Jul 16, 2013, at 6:33 PM, Luke Hoban wrote:
All current engines I could try return Number.prototype for:
12[“__proto__”]
But the new spec says this should be a TypeError.
It’s more consistent with the other members of Object.prototype to do an
implicit ToObject here, and
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com]
Sent: Tuesday, July 16, 2013 7:02 PM
To: Luke Hoban
Cc: es-discuss
Subject: Re: 12[__proto__]
On Jul 16, 2013, at 6:33 PM, Luke Hoban wrote:
All current engines I could try return Number.prototype for:
12[__proto__]
But the new spec says
And if so, where in the spec docs can I read more about it?
Cheers,
Behrang Saeedzadeh
http://www.behrang.org
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 17, 2013 at 12:14 AM, Behrang Saeedzadeh behran...@gmail.comwrote:
And if so, where in the spec docs can I read more about it?
No, but Object.observe is:
http://wiki.ecmascript.org/doku.php?id=strawman:observe
Rick
___
es-discuss mailing
31 matches
Mail list logo
