WeakMap not the weak needed for zombie views

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Mon Jul 7 03:18:52 PDT 2014


On Mon, Jul 7, 2014 at 12:44 PM, Till Schneidereit <
till at tillschneidereit.net> wrote:

> Ah, no, you didn't - I misunderstood your argument and did indeed think it
> was about caching. I'm still hesitant about this particular argument
> because it seems like your framework would still have issues with delayed
> cleanup if it relied on GC to do that. I know, however, that in practice
> it's Hard to ensure that all references in a complex system are properly
> managed (especially in scenarios involving third-party code as you
> describe), so I also don't think this can be outright dismissed.
>

True. However, I think that the non-determinism will not help the situation
of a complex system as it can introduce more leaks. For example, the custom
event handler scenario can trigger handlers that would otherwise be dead,
and those handlers might cause other things to become active again, so it
requires even deeper a level of understanding of the system to reason with
this than with manual cleanup. I find this a similar issue to null pointer
exceptions caused when somebody else cleans up your stuff but forgets to
tell you, so the way I see it it's just replacing one class of problems
with another.

Still, I also acknowledge that weak references have their place in making
reasoning about systems easier. For example WeakMap already solves a lot of
the problems that are caused by not knowing the lifecycle of a (possibly
3rd party) closure. For example, if the closure holds some state that's
associated with an object provided as an input to the closure, it can use
the object as the key and then GC can just do it's job as the closure holds
no strong references to its inputs or outputs. I'm just not very convinced
that adding any features that make GC observable solve any problems big
enough to justify the problems caused.

Cheers,
Jussi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140707/59be00fc/attachment.html>


More information about the es-discuss mailing list