On Tue 29 Apr 2014 20:35, David Herman dher...@mozilla.com writes:
it's a bad smell if code that creates an iterator in a for-of loop
head, loops over it, and *never even touches the iterator directly*
doesn't shut down the iterator.
There are no other objects in JS that have a finalization
On 29 April 2014 20:35, David Herman dher...@mozilla.com wrote:
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
Indeed I expect that in
practice most iterators in an ES6 program will be map, set, and array
iterators, which in practice will not be implemented with generators.
2014-04-30 3:29 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Again, there is nothing new here. At the very least you should look at
the old discussion about this.
Pointers to the old discussions:
I first commented on [[Origin]] as part of my review of the first ES6 draft
Proxy spec:
I also note
this is the first JS construct that would introduce the notion of
resource acquisition and also of implicit finallies.
And that is why late changes like this are risky. As far as I know,
there's been no published work exploring how this aspect of for-of would
interact with
I don't think I understand the issue. AFAICT, all the system implemented
iterators don't need to clean up anything that's not already cleaned up by
GC, so they wouldn't need a .return method anyway. Is there a
counter-example?
On Wed, Apr 30, 2014 at 3:48 AM, Andreas Rossberg
On Tue, Apr 29, 2014 at 4:32 AM, Kevin Smith zenpars...@gmail.com wrote:
I agree with pretty much everything Andy had to say, and would like to add
a meta-perspective:
We should be viewing this as a last-minute feature request. The churn
that this request has introduced is (in my opinion)
Can someone summarize the argument as to why this can't be added later? Is the
fear that people will create iterators with `return` methods and depend on
those methods *not* being called, but then ES7 would start calling them?
___
es-discuss mailing
Domenic: the argument against is that changing the semantics of `for of` --
and all of the standard library methods, in the case of exceptional exit --
would result in a user-visible change to the state of the iterator. That
is, the iterator would not be closed, whereas ES6 as it stands now would
On Tue, Apr 29, 2014 at 7:47 PM, David Herman dher...@mozilla.com wrote:
Promised you a reply to this one, sorry -- I'm not comfortable with this
restriction. It violates my Schemer's intuition [1]. In particular it
creates a number of refactoring hazards: (1) add some try/finally
[...]
[1]
I'm not concerned about manually added .return methods, nor manual calls to
.return methods, though perhaps I should be. If this is a concern, we could
solve it by using an @return symbol in ES7 rather than a string name.
Neither am I concerned about system iterators, assuming that none of the
I'm not pointing out an issue in particular, just explaining why Andy
is right with his specific statement about implementations not using
generators (which Dave seemed surprised about, or have misread, I'm
not sure).
(You are right to assume that built-in iterators would not need .return.)
On Tue, Apr 29, 2014 at 7:49 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The idea is that a Proxy can define its own property descriptor formats that
it exposes to and accepts form user code. vis
Object.defineProperty/Object.getOwnPropertyDescriptors. This includes the
possibility
On Tue, Apr 29, 2014 at 8:08 PM, Mark S. Miller erig...@google.com wrote:
There aren’t any internal invariant sensitivities that I could find. Once
such a non-standard descriptor is never directly used by any of the ordinary
object MOP operations
I'm surprised and alarmed by this, and it
This is a stop-the-train scale disaster. ES6 cannot ship in this state. We
need to fix this asap.
My apologies for not tracking this issue better earlier. I thought we had
all agreed on the constraints, so I did not pay sufficient attention to
what I thought was merely the ironing out of minor
On 4/30/14, 3:09 AM, Andy Wingo wrote:
There are no other objects in JS that have a finalization facility or
other shut down semantics.
This has actually come up as a problem for DOM objects. Some people
actually want a semi-generic facility to say I'm done with you instead
of having to
This was never resolved and the spec is incomplete here
On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
So here is another concern, about the scheme we agreed to last week.
It needs to match a found own property against the possibility of an own
@@unscopable
Specifying the duplicated lookup is doable but a pain. That and the semantic
issues WRT proxies makes me a lot less comfortable with the added complexity
of supporting @@unscopable.
I never liked it. It burdens the language in order to support legacy code. Are
there other ways of fixing
On Wed, Apr 30, 2014 at 1:14 PM, Axel Rauschmayer a...@rauschma.de wrote:
Specifying the duplicated lookup is doable but a pain. That and the
semantic issues WRT proxies makes me a lot less comfortable with the added
complexity of supporting @@unscopable.
I never liked it. It burdens the
On Wed, Apr 30, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Apr 30, 2014 at 1:14 PM, Axel Rauschmayer a...@rauschma.dewrote:
* Hard-coding `with` to ignore only Array.prototype.values.
My main use case for unscopable is for DOM. Today we cannot add nice named
Including Tom because proxies and MOP.
/be
Erik Arvidsson wrote:
This was never resolved and the spec is incomplete here
On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
So here is another concern, about the scheme we agreed
2014-04-30 18:55 GMT+02:00 Mark Miller erig...@gmail.com:
This is a stop-the-train scale disaster. ES6 cannot ship in this state. We
need to fix this asap.
I agree we need to revisit and iron out the details asap, but keep your
calm. I'm sure we'll be able to fix this well in time before the
My main use case for unscopable is for DOM. Today we cannot add nice named
methods to Element or any of its superclasses since HTML attribute event
handlers uses ObjectEnvironments.
So Element.prototype is in the variable scope chain of event handlers? Wow. Is
this documented somewhere?
On 4/30/14, 2:49 PM, Axel Rauschmayer wrote:
So Element.prototype is in the variable scope chain of event handlers? Wow. Is
this documented somewhere?
You mean other than in the spec? See
On 30 Apr 2014, at 21:17 , Boris Zbarsky bzbar...@mit.edu wrote:
On 4/30/14, 2:49 PM, Axel Rauschmayer wrote:
So Element.prototype is in the variable scope chain of event handlers? Wow.
Is this documented somewhere?
You mean other than in the spec? See
On May 1, 2014, at 2:50 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
As specified, proxies can do this:
js Object.isFrozen(proxy)
true
js Object.getOwnPropertyDescriptor(proxy).configurable
true
No, that is not the intent. However, Object.isFrozen depends upon the
Where do you find the spec incomplete WRT @@unscopable. My recollection was
that it was all resolved and fully specified and that I was relatively happy
with the outcome.
Allen
On May 1, 2014, at 3:00 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
This was never resolved and the spec is
On May 1, 2014, at 2:50 AM, Jason Orendorff jason.orendorff at gmail.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
/
// As specified, proxies can do this:
//
// js Object.isFrozen(proxy)
// true
// js Object.getOwnPropertyDescriptor(proxy).configurable
// true
/
No,
Where do you find the spec incomplete WRT @@unscopable. My recollection was
that it was all resolved and fully specified and that I was relatively happy
with the outcome.
unscopables for the Object Environment Record is always the empty list.
It's never populated.
Allen
On May 1,
On Wed, Apr 30, 2014 at 5:17 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Where do you find the spec incomplete WRT @@unscopable. My recollection
was that it was all resolved and fully specified and that I was relatively
happy with the outcome.
I thought so too but now that I look at
On Wed, Apr 30, 2014 at 4:06 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On May 1, 2014, at 2:50 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
As specified, proxies can do this:
js Object.isFrozen(proxy)
true
js Object.getOwnPropertyDescriptor(proxy).configurable
true
I have a use case for `Object.getOwnPropertyDescriptors` – it may or may
not be to your liking, but I have one. I'm currently implementing a library
to help with employing more pure functional programming techniques in
JavaScript environments. This includes such things as (mostly) forcing
The changes from https://bugs.ecmascript.org/show_bug.cgi?id=1908 never
made it into the spec.
On 4/30/2014 11:41 PM, André Bargull wrote:
Where do you find the spec incomplete WRT @@unscopable. My recollection was
that it was all resolved and fully specified and that I was relatively happy
The algorithms in the spec bug uses an object and HasOwnProperty check
instead of an array and looping from 0 to length - 1. That has a lot of
benefits since there are less things that can go wrong (no getters, no
toString etc).
However, we might want to change to use HasProperty instead of
Want to mention
https://github.com/jlongster/es6-macros
while this thread is still live.
/be
Kevin Smith wrote:
https://github.com/zenparsing/esparse
The actual transpiler is at https://github.com/zenparsing/es6now. I
really need to add some documentation, but you can play with
The correct code was in rev21, but somehow got lost in rev22 and later. What
is currently in the spec. is essentially what was in rev20.
Allen
On May 1, 2014, at 7:53 AM, André Bargull andre.barg...@udo.edu wrote:
The changes from https://bugs.ecmascript.org/show_bug.cgi?id=1908 never made
35 matches
Mail list logo
