On Mon, Jul 7, 2014 at 12:44 PM, Till Schneidereit < [email protected]> 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
