Immediate closing of iterators

Brendan Eich brendan at
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  
>> cannot
>> > 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 mailing list