How to ensure memory leak protection?
in [JavaScript]
|
From: Garrett Smith on 26 Jul 2010 01:34 On 2010-07-25 07:40 PM, David Mark wrote: > On Jul 25, 10:29 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-22 10:34 AM, Richard Cornford wrote:> On Jul 22, 2:48 pm, Josh Russo wrote: >>>> On Jul 22, 9:50 am, David Mark wrote: >>>>> On Jul 22, 5:08 am, Josh Russo wrote: [...] > The chain will be broken on remove anyway. You have to handle the > case where the application does not remove the listeners. > It's the developer's job to remove event handlers if needed. Another approach is to take advantage of event delegation and to design widgets that do not keep references to elements that may be removed. -- Garrett
From: David Mark on 26 Jul 2010 01:42 On Jul 26, 1:34 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-25 07:40 PM, David Mark wrote:> On Jul 25, 10:29 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >> On 2010-07-22 10:34 AM, Richard Cornford wrote:> On Jul 22, 2:48 pm, Josh Russo wrote: > >>>> On Jul 22, 9:50 am, David Mark wrote: > >>>>> On Jul 22, 5:08 am, Josh Russo wrote: > [...] > > The chain will be broken on remove anyway. You have to handle the > > case where the application does not remove the listeners. > > It's the developer's job to remove event handlers if needed. If needed? You mean if the developer screwed up and created circular references involving host objects. In that case, it is the job of the developer to clean up their mess (which they shouldn't have made in the first place). But in general, applications decide when they want to add/remove listeners. > > Another approach is to take advantage of event delegation and to design > widgets that do not keep references to elements that may be removed. Just don't create circular references. How many years has it been since I first demonstrated the pattern? I believe Kangax recently blogged about it (explaining it in more detail) on Microsoft's Script Junkie site. Check it out! ;)
From: Garrett Smith on 26 Jul 2010 01:58 On 2010-07-25 10:42 PM, David Mark wrote: > On Jul 26, 1:34 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-25 07:40 PM, David Mark wrote:> On Jul 25, 10:29 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>> On 2010-07-22 10:34 AM, Richard Cornford wrote:> On Jul 22, 2:48 pm, Josh Russo wrote: >>>>>> On Jul 22, 9:50 am, David Mark wrote: >>>>>>> On Jul 22, 5:08 am, Josh Russo wrote: [...] > >> >> Another approach is to take advantage of event delegation and to design >> widgets that do not keep references to elements that may be removed. > > Just don't create circular references. That phrase is superfluous (and trite) to what was explained. -- Garrett
From: David Mark on 26 Jul 2010 08:34 On Jul 26, 1:58 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-25 10:42 PM, David Mark wrote:> On Jul 26, 1:34 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >> On 2010-07-25 07:40 PM, David Mark wrote:> On Jul 25, 10:29 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>> On 2010-07-22 10:34 AM, Richard Cornford wrote:> On Jul 22, 2:48 pm, Josh Russo wrote: > >>>>>> On Jul 22, 9:50 am, David Mark wrote: > >>>>>>> On Jul 22, 5:08 am, Josh Russo wrote: > [...] > > >> Another approach is to take advantage of event delegation and to design > >> widgets that do not keep references to elements that may be removed. > > > Just don't create circular references. > > That phrase is superfluous (and trite) to what was explained. On the contrary, combined with my many previous examples and explanations, it's the proverbial key to the kingdom. You solve the problem by avoiding it. You don't like it because you didn't think of it first. :)
From: Thomas 'PointedEars' Lahn on 26 Jul 2010 21:18
David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> David Mark wrote: >> >> > Josh Russo wrote: >> >> >> David Mark wrote: >> >> >> > The objects that jQuery's "$" function return are somewhat >> >> >> > array-like but have nothing to do with arrays. They are simply >> >> >> > Object objects (as opposed to Array objects). >> >> >> You are correct. I took a look again and they are creating objects >> >> >> with array like properties. What I thought they were doing was >> >> >> adding custom functions/methods to an array instance. >> >> ^^^^^ >> >> > There are no instances in JS. :) >> >> >> >> Wrong. You want to read the ECMAScript Language Specification, any >> >> Edition. >> >> > ISTM that the term instances is associated with classes, >> >> No doubt about that. But not exclusively to class-based OOP. > > Well, as there are no classes in JS... Given your clarification below, you are clearly wrong. >> > of which there are none in JS. >> That would depend on what one understands "classes" and "JS" to be, >> especially the latter. > > As you likely know, I am referring to ECMAScript implementations (e.g. > JScript, JavaScript, etc.) JavaScript 2.0 is an ECMAScript implementation, and it has classes (though by contrast I do not know if it is productively used). JScript 7.0 and above are ECMAScript implementations, and they have classes. ActionScript 2.0 and above are ECMAScript implementations, and they have classes. Do I need to go on? >> > Of course the language used in specifications can often be confusing >> > when dropped into a general discussion. >> >> But not in this case. I am not saying that the OP was aware that they >> were referring to the wrong thing by the right name (it is rather likely >> that they were not, given common misconceptions about these languages); I >> am saying that your statement in its absoluteness is simply wrong. > > I suppose it depends on perspective. I would submit that it depends instead on whether one wants to be consistent or not. Either we accept the terminology as provided by the Specification, or we do not. The consensus appears to be that we accept it, so we really should accept *all* of it. >> > [snip red herring] >> >> The term that has been used here is only incorrect in that it should >> >> have been a capital `A' at the beginning. >> >> > I would have called it an Array object. >> >> I would have a few years ago; not anymore. >> >> > Doesn't that make more sense? >> >> No. If we adopt the custom that for simplicity the name of the property >> that refers to an object is used as the name of that object (see "window >> object" aso.), then "Array object" would specify the Array constructor, a >> Function instance, instead. > > Interesting twist, but when I say "window object", I am referring to > the object. The fact that it is referenced by a property of the > Global Object doesn't really enter into it. And if you say "Function object" you are not referring to that object referred to by the identifier? How is one supposed to know the difference? This approach leads into chaos. >> > Like all JS objects, it is constructed, not instantiated. >> We've been over this. The term instance as used in the Specification >> (and I am not talking about `instanceof') helps to differentiate between >> the object created with a constructor and the constructor object itself, >> to begin with. > > Yes, I suppose it is more concise than saying the "constructed > object", but still the term "instance" is part of what leads to > confusion among those who are used to class-based languages. So do other terms; yours is not a sound argument. >> Like many other terms in the Specification. It does not make sense to >> invent different terminology when the existing one suffices. > > Who's inventing? You, or rather all of us did, until closer inspection of the Specification showed `instance' to be a rather well-defined term (beyond `instanceof'). PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:160 |