Proxy objects and collection

Daurnimator quae at daurnimator.com
Tue Sep 2 11:07:52 PDT 2014


I'd like to submit a request for some sort of Proxy collection
notification, so resources can be freed.
This will greatly help with language interoperability.


I'm the maintainer of lua.vm.js[1], which allows Lua code to run in the
browser.
I've managed to construct a simple and robust cross-language bridge, so
that Lua code can interact with Javascript objects.
When the Lua no longer references the Javascript object, its garbage
collector notifies me (via the __gc metamethod[2]).
At this point, I drop the reference to the JS object, and the JS garbage
collector can collect it if needed.
However, currently, exposing a Lua function or object to Javascript does
not have the same ability;
there is no way (that I know of) to know when Javascript no longer needs
your object.

Example use case:
A Lua script wishes to have a Lua function called on an interval:
`timerid = window:setInterval(function() window.console:log("ping") end)`
Later, it wishes to clear the timer:
`window:clearInterval(timerid)`
This will stop the function from being called, but I have no way to notify
Lua that the function can be collected.


The closest thing maturing in this direction seems to be Revocable
proxies[3].
However, these still require a manual function call to `revoke` on the
Javascript side of things.

So, I'd like to see some sort of "trap" that is fired when a Proxy is
collected.
To prevent over specifying how Javascript garbage collectors should operate,
I propose that the trap *may* only be called at some *undefined* point
after the object is not strongly referenced.


Regards,
Daurn

[1] https://kripken.github.io/lua.vm.js/repl.html
[2] http://www.lua.org/manual/5.2/manual.html#2.5.1
[3]
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#revocable_proxies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140902/2150c413/attachment.html>


More information about the es-discuss mailing list