Weak event listener

Kevin Gadd kevin.gadd at gmail.com
Tue Apr 2 21:40:18 PDT 2013

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130402/d55741ca/attachment.html>

More information about the es-discuss mailing list