Hi,

I've been reading about WeakMap in the draft. To my surprise, it is
not at all what I thought it would be or what I was hoping to use. At
least that is my understanding.

My use case is in MV* architectures. With current MV* frameworks, a
model holds strong references to the views observing that model. If a
view is removed from the DOM, all other references in the application
are lost to that view, but the view never stopped observing the model
object, that strong reference from model to view results in a zombie
view. Avoiding this means views need to have `destroy` methods that
unsubscribes the view from the model. It is easy for the application
programmer to forget to call a view's `destroy` method and the
application leaks memory. As a result of the leak, the user experience
and ultimately the reputation of the Web suffers. If a model could
hold weak references to its observers, this would safeguard against
accidental and inevitable application programmer forgetfulness.

It appears that WeakMap cannot help solve the current MV* zombie view
problem. Or did I miss something?

I was expecting WeakMap to hold its values weakly and set them to
undefined or delete the associated key when the value was garbage
collected.

Does anything exist or is coming to help solve the zombie problem?

----

Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds
its keys weakly. The difference compared with the ECMAScript WeakMap
is that instances of WeakIdentityKeyDictionary have an iterator so the
observers can be stored as the keys and still discoverable without
keeping other strong references. The ECMAScript standard specifically
disallows in iterator.

Thanks,
Peter

I've been reading about WeakMap in the draft. To my surprise, it is
not at all what I thought it would be or what I was hoping to use. At
least that is my understanding.

My use case is in MV* architectures. With current MV* frameworks, a
model holds strong references to the views observing that model. If a
view is removed from the DOM, all other references in the application
are lost to that view, but the view never stopped observing the model
object, that strong reference from model to view results in a zombie
view. Avoiding this means views need to have `destroy` methods that
unsubscribes the view from the model. It is easy for the application
programmer to forget to call a view's `destroy` method and the
application leaks memory. As a result of the leak, the user experience
and ultimately the reputation of the Web suffers. If a model could
hold weak references to its observers, this would safeguard against
accidental and inevitable application programmer forgetfulness.

It appears that WeakMap cannot help solve the current MV* zombie view
problem. Or did I miss something?

I was expecting WeakMap to hold its values weakly and set them to
undefined or delete the associated key when the value was garbage
collected.

Does anything exist or is coming to help solve the zombie problem?

----

Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds
its keys weakly. The difference compared with the ECMAScript WeakMap
is that instances of WeakIdentityKeyDictionary have an iterator so the
observers can be stored as the keys and still discoverable without
keeping other strong references. The ECMAScript standard specifically
disallows in iterator.