es-discuss Digest, Vol 41, Issue 9

Brendan Eich brendan at
Sun Jul 4 01:09:14 PDT 2010

On Jul 4, 2010, at 12:46 AM, Leo Meyerovich wrote:

> ... then I still don't see how to do an encoding of weak references that isn't invasive (e.g., adding in a user-level GC that constructors are somehow guaranteed to go through). For a non-invasive approach, there might be probablistic guarantees achieved by API restrictions (e.g., limit the number of bad guesses of IDs for the otherwise forgeable ID->object function) or a creative use of lexically scoped regions, but I'm skeptical of anything complicated like that. 

I don't see the connection. We're talking about Ephemeron (Tables) as primitives in the language. The GC definitely has to know about them. Likewise for hashcode: if the object's address is one-way hashed to the hashcode() result, but the GC moves the object, then the object will need to grow a field to store its invariant hashcode.

> Did you have something in mind in how hashes (or some other feature) enable weak references / dictionaries? It didn't jump out at me and I want them :)

We're not looking to enable anyone to build weak structures in JS without help from a new primitive dedicated to that task, which also avoids leaking information about finalization, addresse, etc. Modulo naming, the Ephemeron Table proposal is that new and harmonious primitive.

We are considering adding Object.identity/hashcode to support user-created implementations of strong-key sets, maps, trees, etc. Those are useful too. Not every object-to-* use-case requires an EphemeronTable.


More information about the es-discuss mailing list