Immediate closing of iterators

Brendan Eich brendan at mozilla.org
Tue Jan 2 12:30:55 PST 2007


On Jan 1, 2007, at 8:36 AM, 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?

> As for the spec not specifying threading behavior, I would claim that
> this issue _forces_ you to specify it.  If my program relies on
> nothing but the semantics defined in the spec then the program should
> run correctly on all spec-compliant implementations.  If the spec
> leaves this question unanswered then I can't hope to write
> implementation- or embedding-independent code.

It's true that ECMA-262 alone cannot be used to write portable "JS",  
across (e.g. tellme.com's) VXML server, Macromedia server, Web  
server, and Web browser embeddings, just to name some embeddings with  
different execution models.

>   If the spec doesn't
> explicitly disallow close methods to be run preemptively then you
> have, in effect, introduced multi threading -- at least, if I want to
> write an implementation-independent program I have to consider the
> possibility that there will be (spec compliant) implementations that
> finalize preemptively.

The spec should not automate close calling from the GC, we agree, so  
(I hope we agree that) it can go back to sticking its head in the  
sand and pretending the world is single-threaded.  Its SML-NJ  
reference implementation will not use threads in any way that could  
violate the run-to-completion model.

> On the other hand, if you do disallow close methods to be run
> preemptively then you're more or less guaranteeing that on any
> compliant implementation, close methods will _not_ be run in a timely
> fashion, since they will have to wait for the script to finish.

The important timely-close use-case is the for-in loop. I can't think  
of any others that aren't contrived. But we agree, so it would be  
helpful for others on the list who see things differently (including  
you Pythonistas) to speak up.

/be



More information about the Es4-discuss mailing list