Immediate closing of iterators
brendan at mozilla.org
Tue Jan 2 15:48:16 PST 2007
On Jan 2, 2007, at 3:23 PM, Chris Hansen wrote:
>> > In the absence of finalization none of these problems occur because
>> > then the collection or non-collection of an unreachable object
>> > be observed from the program.
>> Thanks, this is the compelling argument for C#-style close automation
>> (i.e., the ES4 spec automates close calling on exit from for-in and
>> for-each-in loops only); all other generator use-cases that want
>> close must do it themselves. As I've said several times, I'm in
>> agreement. Is everyone else?
> We agree about C#-style close and that's not what I'm arguing for.
> I'm arguing against having automatically closing of generators that
> are not used in for-in loops, for instance ones used as coroutines.
> It's not my impression that we agree there.
No, we agree. That's what I keep saying ("I'm sold", etc.), and the
above words are intentionally exhaustive: "all other generator use-
cases [than for-in loops] that want close must do it themselves."
Sorry if I was unclear. You and I have always agreed that timely
release of scarce resources should not depend on GC, but for JS1.7
(in Firefox 2), we followed Python 2.5 closely for the sake of
guaranteeing finally execution when the last yield is from the
matching try. This seems to cater to bad practices; it creates a
hazard for users, especially those coming from the Python world.
Still troubling, but less so, is the problem for Python people who
expect close to be automated in non-for-in-loop cases.
>> The important timely-close use-case is the for-in loop. I can't think
>> of any others that aren't contrived.
> You could easily imagine using generators to access files, networks
> sockets or other external resources, and I don't think it is contrived
> to imagine such a generator used outside a for-in loop. In that case
> you don't need prompt finalization and that's not what I mean when I
> say "timely fashion", but you would want it to happen eventually and
> you probably don't want too much time to pass before it happens.
This is a use-case mentioned in the PEPs, but as you've argued it
limits GC implementation choices if ES4 were to require it. Since at
least one ECMA member's ECMA_262 + ES4-like extensions implementation
(ActionScript 3 in the Flash Player) uses conservative GC, I do not
believe that TG1 will or should specify any further close automation
than for for-in loops. That's my opinion, at any rate.
Expect more responses, I've reminded interested people about this list.
More information about the Es4-discuss