Weak event listener

David Bruant bruant.d at gmail.com
Mon Apr 1 05:34:33 PDT 2013

Le 27/03/2013 00:22, Kevin Gadd a écrit :
> OK, it seems like Weak References are now being discussed without the 
> context of previous discussions of weak references, which is a little 
> annoying. Non-contrived real-world use cases that require Weak 
> References (or a primitive with similar capabilities, like a Map with 
> weak values instead of weak keys, I'm not picky) have already been 
> provided *on this list* the last time WRs were discussed. I provided 
> two based on real applications I've worked on; I thought other people 
> in the discussion thread provided more.
I've been through the thread and I haven't read any use case that 
*requires* Weak References. Only use cases where they make life easier 
to various degrees. It's been agreed that in most cases, adding an 
explicit .dispose() or equivalent protocol could work too.
The only use case where I have some intuition of WeakRefs making a 
significant difference is the data binding use case. I find the "compile 
weakrefs from another language" use case a bit too early since compiling 
to JS is such a recent trend.
As I said in one message, there is always a need of cutting some 
reference somewhere [1] for WeakRefs to work.

> What process needs to be followed before people will believe that Weak 
> References are a real primitive that solves real problems? Do you need 
> a set of broken, non-functional 'real world' applications written in 
> JS that work in a customized version of V8/SpiderMonkey that has WRs? 
> Do you need more verbose descriptions of use cases than previously 
> provided? I can try to provide more justification than I did 
> previously if this is necessary; I wasn't aware that it was.
 From what I read, until Jason joined the discussion, it was mostly me 
that was being annoying on use cases. So I can give my criteria if that 
helps (as a reminder, I'm not part of TC39, so you're also free to 
ignore what I say).
I'd like to see the description of a use case (something more specific 
than just "data binding") and an implementation that has been thought 
with memory management in mind. If this implementation proves to be 
minimalistic and simple enough, but yet too complex to use without 
WeakRefs, I'll be convinced.
The "thought with memory management in mind" part is important. I don't 
think I have ever seen a talk describing a library where the author 
talked about the lifecycle of the objects created/used by the library. 
Memory footprint is sometimes discussed, but not lifecycle. From what 
I've observed, it's only after a severe memory leak is observed that 
people start to think about object lifecycle. Obviously, at that time, 
it's sometimes too late to do major refactoring and a lot of people 
would love to have weakrefs as a quickfix tool.
 From what I've observed too, very few people seem to understand GC at 
all. A lot of people still cite "cycles" as an issue of GC. So I wonder 
how many people really think of object lifecycles properly when 
designing libraries/frameworks.

But what if object lifecycle was considered in the design? Maybe we'd 
realize WeakRefs are necessary to dramatically reduce the 
burden/boilerplate of some use cases. Maybe we'd find out a different 
way of designing libraries and realize WeakRefs aren't that necessary 
after all.

Maybe tomorrow, i'll be writing a library and see the light or see the 
design of a library and see the light that without weakrefs, life is so 
much harder. I haven't yet come across such a case, so I'm not convinced 


[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/028935.html

More information about the es-discuss mailing list