On Jun 8, 2013, at 10:34 PM, Axel Rauschmayer wrote:
I can’t find the rationale as to why that isn’t allowed. Is it because
iterators can’t be recognized as safely as iterables?
Both Iterators and Iterables may be ordinary objects. There has to be some way
for for-of to recognize one or
I can’t find the rationale as to why that isn’t allowed. Is it because
iterators can’t be recognized as safely as iterables?
Both Iterators and Iterables may be ordinary objects. There has to be some
way for for-of to recognize one or the other. The way that an Iterable is
recognized is
It seems easy enough to define a class that has a @@iterator() {return this}
method and then to subclass class it for you specific Iterables.
One more thing that might be problematic with the current approach: If you
create combinators for iterators (similar to Python’s itertools [1]) then
On Sun, Jun 9, 2013 at 2:17 AM, Axel Rauschmayer a...@rauschma.de wrote:
Another use case for iterator support: retrieve the first element from an
iterator, then iterate over the remaining elements via for-of.
Right, this happens whenever you're doing a fold and your combining
function has no
2013/6/8 Till Schneidereit tschneider...@gmail.com
I just saw that Jason identified some additional open questions in [1]:
1. What happens when we call a method on an object whose [[Prototype]] is
a proxy with an invoke trap?
var p = new Proxy({}, {invoke: ...});
var q =
Hi David,
2013/6/7 David Bruant bruan...@gmail.com
Le 02/06/2013 09:46, Rick Waldron a écrit :
4.4 Proxies
Proxy Invoke Trap and wrong |this|-binding on built-in methods
AWB: with current default behavior of “get”, “Caretaker” will break on
built-ins such as Date, because the |this|
On Jun 9, 2013, at 8:18 AM, Tom Van Cutsem wrote:
I believe Allen had previously experimented with an invoke trap (called
callProperty) in a fork of the ES6 draft. Allen, can you comment on how you
would see [[Invoke]] specced?
I've already updated my working draft with [[Invoke]], but
Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
I think your analysis is mostly right: if we want to make e.g.
Date.prototype.getTime.call(proxy) work, then the easiest way to fit
that into the current design would be to add Date-specific traps (and
Map-specific, Set-specific, Regexp-specific,
On Sun, Jun 9, 2013 at 4:18 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
No, we can't just blindly call GetValue in step 1 as that would lead to the
get trap being invoked on a proxy (which is the wrong trap).
Why can't we have the two traps trigger?
I would imagine that proxies are meant to
Le 09/06/2013 12:50, David Bruant a écrit :
Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
For full transparency across isolated object graphs, I think
membranes are still the way to go.
I don't understand that part. A membrane (with shadow targets?) will
have the same problem as a proxy alone
2013/6/9 Brian Di Palma off...@gmail.com
On Sun, Jun 9, 2013 at 4:18 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
No, we can't just blindly call GetValue in step 1 as that would lead to
the
get trap being invoked on a proxy (which is the wrong trap).
Why can't we have the two traps
On Jun 8, 2013, at 3:30 AM, Till Schneidereit wrote:
At the last TC39 meeting, an agreement was reached for proxies to support an
Invoke trap.
Finally (I remember that long thread 2 years ago when I was advocating for it).
Curious what was the reasoning behind this now, since as I
At two TC39 meetings, members of TC39 expressed deep concern about the
prospect of incompatible changes to JSON by the IETF.
Those concerns have not been expressed directly to the IETF's JSON Working
Group. I say this as one of the two co-chairs of the JSON WG. If TC39 wants
to express deep
On Sun, Jun 9, 2013 at 7:19 PM, Paul Hoffman paul.hoff...@gmail.com wrote:
At two TC39 meetings, members of TC39 expressed deep concern about the
prospect of incompatible changes to JSON by the IETF.
Those concerns have not been expressed directly to the IETF's JSON Working
Group. I say this
Thanks, but that doesn't match what Yehuda said. If anything, it shows that
there is as widespread disagreement within TC39 as to what is a breaking
change with respect to duplicate names in objects as there so far is in the
JSON WG.
If there are other public minutes that relate to the TC39-IETF
Allen Wirfs-Brock wrote:
Currently the spec. days that if it is not an Iterable the for-of loop
doesn't run (although some of the details in the For In/Of Expression
Evaluation looks a little bogus). It would be easy enough to to spec.
it such that if the value is not an Iterable (does not
Paul Hoffman wrote:
At two TC39 meetings, members of TC39 expressed deep concern about
the prospect of incompatible changes to JSON by the IETF.
Those concerns have not been expressed directly to the IETF's JSON
Working Group.
That's surprising -- am I the only one on TC39 who thought Doug
Paul Hoffman wrote:
Thanks, but that doesn't match what Yehuda said. If anything, it shows
that there is as widespread disagreement within TC39 as to what is a
breaking change with respect to duplicate names in objects as there
so far is in the JSON WG.
The minutes Rick cited show no
On Sun, Jun 9, 2013 at 10:25 PM, Brendan Eich bren...@mozilla.com wrote:
Paul Hoffman wrote:
Thanks, but that doesn't match what Yehuda said. If anything, it shows that
there is as widespread disagreement within TC39 as to what is a breaking
change with respect to duplicate names in objects
19 matches
Mail list logo
