How to ensure memory leak protection?
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 22 Jul 2010 02:53 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. The term that has been used here is only incorrect in that it should have been a capital `A' at the beginning. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: David Mark on 22 Jul 2010 03:24 On Jul 22, 2:53 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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, of which there are none in JS. Of course the language used in specifications can often be confusing when dropped into a general discussion. For example, the DOM specifications refer to DOM properties as some sort of attributes. And, as has been discussed repeatedly, the instanceof operator has an unfortunate name. This may have been a case of the language designers letting the low-level terminology bubble up into the language itself. In any event, that name has caused confusion. > > 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. Doesn't that make more sense? Like all JS objects, it is constructed, not instantiated.
From: Josh Russo on 22 Jul 2010 05:08 Ok, my original post assumed too much. I should have made the following statements clear: 1) The jQuery object reference offers the same pit falls as a variable containing a DOM reference because the contained DOM reference is publicly accessible within the jQuery object 2) Here I was going to say that the bind method works sufficiently similar to the direct event binding but that doesn't even matter in this case. What matter is the scope of the event listener function when it's declared. So #1 is the only thing I really missed in my original post. If there are no instances in JS, how do you refer to X and Y below? var X = []; var Y = []; As for learning more about prototyping and how it's different, do you have a recommendation for a good reference website?
From: Asen Bozhilov on 22 Jul 2010 09:50 Josh Russo wrote: > I'm a little confused about how best to handle user objects that > manage multiple DOM objects. > > I was readinghttps://developer.mozilla.org/en/a_re-introduction_to_javascript > and it seems like my preferred pattern seems like it's exactly what > I'm not suppose to do. > > function Widget(){ > this.myfield = $('#id_myfield'); > var clickHandler = function(event){ //do something }; > this.myfield.bind('click', clickHandler); > > } Just rewrite it in a proper way. var Widget = (function () { function onClick(evt) { //... } return function (widgetId) { this.myfield = document.getElementById(widgetId); util.addListener(this.myfield, 'click', onClick); }; })(); /** * Do something with `myfield' member */ Widget.prototype.method = function () { //... };
From: Josh Russo on 22 Jul 2010 10:16
On Jul 22, 12:50 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > Josh Russo wrote: > > I'm a little confused about how best to handle user objects that > > manage multiple DOM objects. > > > I was readinghttps://developer.mozilla.org/en/a_re-introduction_to_javascript > > and it seems like my preferred pattern seems like it's exactly what > > I'm not suppose to do. > > > function Widget(){ > > this.myfield = $('#id_myfield'); > > var clickHandler = function(event){ //do something }; > > this.myfield.bind('click', clickHandler); > > > } > > Just rewrite it in a proper way. > > var Widget = (function () { > function onClick(evt) { > //... > } > > return function (widgetId) { > this.myfield = document.getElementById(widgetId); > > util.addListener(this.myfield, 'click', onClick); > }; > > })(); > > /** > * Do something with `myfield' member > */ > Widget.prototype.method = function () { > //... > > > > }; Yes, I have started using the above pattern for creation of user objects. I still need to understand the mechanics of prototyping more, but this thread was me just trying to solidify my understanding of why the previous pattern was bad. Once I hit the point in this thread that I really understood what needed to be looked for, a review of my code found none of the patterns I thought I had created. My simplified example didn't actually exist in the many different way my object creation patterns have evolved. Go figure. |