3 ms·

The problem with WeakMaps is that their keys are weak, not the values. While weak keys are useful to provide a place to store extra data about an object, a mor

The problem with WeakMaps is that their keys are weak, not the values. While weak keys are useful to provide a place to store extra data about an object, a more useful ability would be to have weak values, so you could find existing objects by string key, if they haven't been GC'd yet. One big potential use for weak values is in ORMs. When asking for an object with id 5, if one exists you'd like the existing instance. However, you don't want the ORM keeping strong references to all of the instances, preventing them from ever being GC'd if nothing else is using them.

mccr8 14y ago
A drawback of standard weak references is that it exposes garbage collector scheduling to the program, which would make JS programs more nondeterministic. I believe that historically nondeterminism like this has been a source of incompatibility between JS implementations.
- wycats 14y ago
  The current proposals avoid this problem by requiring that objects held by weak references can only be observably collected between turns of the event loop. In short: whenever a WeakReference is dereferenced, a temporary strong reference to the object is created that is dropped at the end of the turn of the event loop. There might still be non-determinism, but it is limited to the type that is already common in JS. Behavior across event turns (i.e. happening in asynchronous callbacks) cannot make any assumptions about what else may have happened between callback registration and callback execution.
wycats 14y ago
WeakMaps are useful for storing auxiliary information without having to pollute third-party objects and without impacting the ability to collect those objects. For example, jQuery stores information on a unique, generated key on DOM nodes. Ember does something similar for meta-information about an object. With WeakMaps, both could store the information in a WeakMap, and avoid polluting the object. WeakMaps are easier to get into the language because the GC-related semantics are unobservable. If you have a key you can use in `get`, the key is by definition not collectible. For reasons involving security leaks, it is more tricky (but not impossible) to add features to the language that allow third-parties to observe when an object is collected. That said, I am personally a strong advocate for Weak References in the language, and have been advocating their inclusion on TC39. Two open proposals are http://wiki.ecmascript.org/doku.php?id=strawman:weak_references http://wiki.ecmascript.org/doku.php?id=strawman:weak_referen... and http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs. Active discussions involve post-mortem-finalization and avoiding security leaks. As the maintainer of Ember and Ember Data, I fully agree with the need for this feature and will continue to work towards including it in the language.
domenicd 14y ago
The values are held weakly in ES6 weak maps.

mccr8 14y ago

A drawback of standard weak references is that it exposes garbage collector scheduling to the program, which would make JS programs more nondeterministic. I believe that historically nondeterminism like this has been a source of incompatibility between JS implementations.

wycats 14y ago
The current proposals avoid this problem by requiring that objects held by weak references can only be observably collected between turns of the event loop. In short: whenever a WeakReference is dereferenced, a temporary strong reference to the object is created that is dropped at the end of the turn of the event loop. There might still be non-determinism, but it is limited to the type that is already common in JS. Behavior across event turns (i.e. happening in asynchronous callbacks) cannot make any assumptions about what else may have happened between callback registration and callback execution.

wycats 14y ago

WeakMaps are useful for storing auxiliary information without having to pollute third-party objects and without impacting the ability to collect those objects. For example, jQuery stores information on a unique, generated key on DOM nodes. Ember does something similar for meta-information about an object. With WeakMaps, both could store the information in a WeakMap, and avoid polluting the object. WeakMaps are easier to get into the language because the GC-related semantics are unobservable. If you have a key you can use in `get`, the key is by definition not collectible. For reasons involving security leaks, it is more tricky (but not impossible) to add features to the language that allow third-parties to observe when an object is collected. That said, I am personally a strong advocate for Weak References in the language, and have been advocating their inclusion on TC39. Two open proposals are http://wiki.ecmascript.org/doku.php?id=strawman:weak_references http://wiki.ecmascript.org/doku.php?id=strawman:weak_referen... and http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs. Active discussions involve post-mortem-finalization and avoiding security leaks. As the maintainer of Ember and Ember Data, I fully agree with the need for this feature and will continue to work towards including it in the language.

domenicd 14y ago

The values are held weakly in ES6 weak maps.