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 <fra...@pwpconsult.com> wrote: > On 4/1/13 at 5:40 AM, sa...@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@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -- -kg
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
