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

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to