Weak event listener

Bill Frantz frantz at pwpconsult.com
Tue Apr 2 21:26:38 PDT 2013


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



More information about the es-discuss mailing list