Weak references and destructors

Brendan Eich brendan at mozilla.com
Fri Dec 11 09:43:43 PST 2009


On Dec 11, 2009, at 12:45 AM, Erik Corry wrote:

> I really dislike this definition.  This would imply that anyone could
> overwrite setTimeout and get a completely different behaviour.  If
> overwriting is impossible then it introduces setTimeout into the
> standard by the backdoor.

I agree -- I should add that my quoting ken's "use brute force"  
chestnut was not meant as an endorsement.

The ES spec should not be jury-rigged on top of not only DOM or  
browser API standards, especially not by "object detectiong" as if  
written in JS code running in the browser. That may be necessary for  
Caja or other present-day translators, but the Harmony-era spec can do  
better, without overspecifying.


> I'd prefer an underspecified [[QueueForProcessing]] operation with no
> connection to the global object and a note to say that in a browser it
> would be expected to use the same mechanism as a setTimeout with a
> timeout of zero.

But then you go on to make an excellent point:


> There are lots of misunderstandings around GC, where people expect
> this sort of callback to happen at some predictable time.  If there's
> no memory pressure then there's no reason to expect the GC to ever be
> run even if the program runs for ever.  It would be nice to have some
> indication in the text of the standard that discouraged people from
> expecting a callback at some predictable time.  For example if people
> want to close file descriptors or collect other resources that are not
> memory using this mechanism it would be nice to discourage them
> (because it won't work on a machine with lots of memory and not so
> many max open fds).

It would be more than nice. It is important that the spec not mandate  
any particular schedule. We have seen endless over-coupling to GC  
implementation details where programmers who can hook into  
finalization or another GC phase do so for all the wrong reasons: to  
close fds, free database cursors, send a message, update UI, etc.  
Crazy stuff.

But if there is no guarantee of when the notification might happen,  
then programmers should not expect any scheduling akin to setTimeout  
with a timeout of zero.

/be



More information about the es-discuss mailing list