I made a small javascript framework designed to add some useful stuff in the prototyped object model (super method call, inheritance, auto init...).

In this framework, some object methods are automatically called, like "init" to construct the object and "destroy" on window unload.

I have two questions about this destroy method :

• What is this method used for?

I think it should do some cleaning on DOM objects (unbind events), but is there other cleaning to do?

• Should this method be called on another event? Is it possible to detect when an object is destroyed and call this method at this time?

If anyone is interested in this framework, I posted it on gitHub, but right now there's no documentation :-/ :

I made a small javascript framework designed to add some useful stuff in the prototyped object model (super method call, inheritance, auto init...).

In this framework, some object methods are automatically called, like "init" to construct the object and "destroy" on window unload.

I have two questions about this destroy method :

• What is this method used for?

I think it should do some cleaning on DOM objects (unbind events), but is there other cleaning to do?

• Should this method be called on another event? Is it possible to detect when an object is destroyed and call this method at this time?

If anyone is interested in this framework, I posted it on gitHub, but right now there's no documentation :-/ : https://github./LeMisterV/EasyPrototype

• javascript
• destructor

• 1 Destroy is called on unload? Well, than the method can do ANYTHING - since it won't have any impact on anything else. After all, the browser is about to navigate away from that page anyway. Destroy methods make sense for ponents destroyed during the lifetime of the webpage. There is nothing to clean up on "unload" for a webapp, unlike for desktop apps, which use the opportunity to write buffers to disk, release file handles, etc. – Mörre Commented Jun 29, 2011 at 14:01
• In Javascript it is not possible to write a method that gets called automatically when/before an object is "destroyed", it has to be called explicitly. What does "destroy" mean anyway in JS? When the object is garbage-collected - which is random? When the last handle to it is released? – Mörre Commented Jun 29, 2011 at 14:04
• I suspect that @Nicolas is worried about memory leaks in IE, which has problems when DOM elements have properties whose values are JavaScript objects, esp. closures. The DOM memory manager doesn't know how to reclaim that space so it doesn't. – Pointy Commented Jun 29, 2011 at 14:04
• @Pointy: There are no mem leaks on UNLOAD even in IE, and generally, destroy() is good to do in other browsers as well - if a ponent is destroyed during the lifetime of a page (some apps don't use show/hide for widgets but do a new Widget()/widget.destroy() cycle each time). – Mörre Commented Jun 29, 2011 at 14:07
• @Mörre I think that IE6 definitely had problems with circular references that would not be freed for the life of the browser process. Here is a write-up from Microsoft, and there are many others available describing the problem. – Pointy Commented Jun 29, 2011 at 14:13

3 Answers 3

A better question, why do you need to destroy anything? if the window is unloading, everything will be garbage collected on your behalf.

Some versions of Internet Explorer get stuck on circular references between JavaScript and the DOM, since they are garbage collected separately. This tends to be an issue when you start adding event handlers to everything.

What you should do in your framework is keep track of every time you add an event so that you can go through that array of events and destroy each of them on unload.

First, and foremost, the reason for a "destroy" (or any destructor) is to bring your "system" or program into a known stable state. In browsers, all memory usage (which is the classic issue) is automatically done for you with Garbage Collection.

So the only reason left why you might want a destructor ("destroy" method) is if there are abstract properties about your system that the object needs to ensure is in a known state.