Weak event listener

Marius Gundersen gundersen at gmail.com
Wed Apr 3 02:13:46 PDT 2013


> 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.

Very few things added to ES6 is *required*, most of them makes the life of
developers easier. Some of them only slightly improves our life (default
variables, spreading, etc), while others change the way projects are
structure (modules, classes, etc). WeakRefs would be such a feature. The
use of WeakRefs instead of a .dispose() method is a major improvement in
workflow, and allows some very interesting projects and data structures. As
Kevin said:

> "A core part of the problem here is that the distinction between an
'important' reference - one that must keep an object alive - and an
'incidental' reference, that only need exist as long as it target does"...

This is a concept which cannot be expressed in JavaScript today, but which
most code actually needs to hint at in some way. Most objects are owned by
one other object, and known by many other objects. The objects which knows
of it shouldn't keep it alive, only the owner should. It is impossible to
distinguish between these two cases in JavaScript today.

An example of this would be a GUI with event listening widgets, which is
usually a tree where each widget is owned by its parent, and a widget
without a parent should stop listening to events. There are many ways to
implement this without WeakRefs, usually involving an explicit _parent_
field and a dispose method when a widget is removed. But with WeakRefs this
could be implemented so only the parent has a strong reference to the
children, everyone else has weak references and so the widget (and all its
children) are garbage collected and stop listening to events when the
parent deletes it.

Hopefully this is enough of a usecase to make WeakRefs (or one of the
alternatives, for example, an iterable set of weak references to
functions/objects).

Marius Gundersen


On Wed, Apr 3, 2013 at 6:40 AM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> An important distinction here - and one I think Bill and Brendan and
> others have gotten at some, and I've been trying to get at - is that weak
> references (and similar concepts, like weak maps and weak event listeners)
> unfortunately encompass a set of different problems and end up being used
> to solve some (or all) of them in different contexts.
>
> Resource management in the traditional 'memory and handles' sense is one
> of these contexts. History has, at this point, pretty much proven that you
> don't need a garbage collector to manage resources, but it has also pretty
> much proven that having one really helps. JS's garbage collector is a real
> win for ease of use (and safety, as Bill points out) in this area, but in
> practice JS rarely actually manipulates raw memory or handles to the extent
> that weak references are sorely needed. In cases where WRs are sorely
> needed, as well, the payoff is often significant enough to justify just
> going through and manually filling your code with calls to .dispose(). I've
> certainly done it dozens of times, and with enough discipline and process
> even big teams with junior programmers can manage it.
>
> The context that motivates me to beg and plead for WRs, though, is a
> different one: Architecture and 'state management', so to speak, where the
> liveness of an object has real, semantic meaning beyond whether the memory
> that holds it has been freed and whether the object is reachable. The
> example I gave of an application with 'modes' is one of the best examples
> of this I've run into in my career, because it was a huge problem that kept
> tripping us up as we maintained and extended the application - being able
> to say at any point whether a mode needed to be alive, and whether its
> associated resources and event listeners needed to be alive, was a really
> big challenge. In some situations we solved this with explicit disposal,
> but in other situations we *absolutely* needed Weak References to keep
> things sane, and going through and manually breaking cycles and removing
> event listeners and nulling parent references simply would not have been
> scalable. Even our best programmers wouldn't have been able to do it
> consistently. A core part of the problem here is that the distinction
> between an 'important' reference - one that must keep an object alive - and
> an 'incidental' reference, that only need exist as long as it target does -
> is really hard (for me, at least) to convey through design/comments and
> enforce manually with code. Having the aid of the type system and the
> runtime here is a huge boon.
>
> This is why the 'build your own malloc'/'build your own collector'/'do
> manual refcounting' solutions feel like a poor choice to me. Those
> solutions do a great job of solving resource management problems, because
> you can apply the cold unfeeling gaze of computer science to your software
> and eventually become confident that you will not have any resource
> management problems. The huge number of developers out there who
> intrinsically trust the garbage collector is great evidence of this. But
> when it comes to solving state/lifetime management problems, and being able
> to easily write code that you feel confident about in those contexts,
> solutions like manual refcounting or writing your own collector feel really
> inadequate. I've never come across a codebase that leaned upon solutions
> like that where you could feel true confidence; I've personally run into
> addref/release bugs in battle-tested codebases like Python and I've
> probably introduced my own more than a few times.
>
> I hope this makes it clearer why I want WeakRefs in particular, and
> perhaps it makes it easier to understand what an alternative solution might
> look like. Maybe the alternative solution is sugar for doing light-weight
> scoped addref/release, like Python's 'with' statement, or some other simple
> mechanism where people can at least confidently build their own solutions
> with the aid of the runtime, I'm not really sure. There are certainly vast
> millions of lines of C++ out there more or less leaning on such constructs,
> and those apps seem to work!
>
>
>
> On Tue, Apr 2, 2013 at 9:26 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
>
>> On 4/1/13 at 5:40 AM, samth at ccs.neu.edu (Sam Tobin-Hochstadt) wrote:
>>
>>  Using `.dispose()` is manual management of the allocation and
>>> deallocation of object. Manual memory management is fundamentally
>>> non-modular -- you can't encapsulate it in a library, and it requires
>>> describing memory management behavior in all your function
>>> specifications, the way that C libraries do.  It's certainly possible
>>> to write large, complex apps in C.  But that's not evidence that we
>>> should bring those practices to JS.
>>>
>>
>> There are a bunch of different reasons for wanting to "dispose" an object
>> in memory. With the malloc/free system from C, you usually dispose objects
>> to recover their backing memory for future use. The C version is not memory
>> safe.
>>
>> If you are paying for the memory, you may be willing to break things to
>> be able to stop paying. There may be some other reasons for causing an
>> object to stop working and as a side effect recover most of its memory. A
>> proxy can provide this service for JS, along with a number of other
>> techniques all of which will be memory safe.
>>
>> For short-lived programs, you can ignore memory disposal if the system
>> running them will free the memory when they exit. This technique is memory
>> safe and even works with mismanagement of references in a garbage collected
>> systems. Having a system which supports just exiting and recovering memory
>> is valuable for ad-hoc programming environments. It might also be valuable
>> for ads running in long-lived web pages. Possibly some of the safe JS
>> execution environments provide this service for the programs they mediate.
>>
>> Memory safety is one really good reason to choose JS over C.
>>
>> Cheers - Bill
>>
>> ------------------------------**------------------------------**
>> -----------
>> Bill Frantz        | "The only thing we have to   | Periwinkle
>> (408)356-8506      | fear is fear itself." - FDR  | 16345 Englewood Ave
>> www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, CA 95032
>>
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
>
> --
> -kg
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130403/64be7b5b/attachment.html>


More information about the es-discuss mailing list