How to ensure memory leak protection?
in [JavaScript]
|
From: David Mark on 26 Jul 2010 21:33 On Jul 26, 9:18 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > 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. I doubt it. > > >> > 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). That one's obviously irrelevant. > > JScript 7.0 and above are ECMAScript implementations, and they have classes. That's JScript.NET, which is an implementation of JScript. Denied as irrelevant. You know full well what ECMAScript implementations I am referring to (the ones that are the subject at hand here 99.9% of the time and typically used to script browsers). > > ActionScript 2.0 and above are ECMAScript implementations, and they have > classes. You are reaching. Do you really think I was including ActionScript in my (abbreviated) list? > > Do I need to go on? Certainly not. > > >> > 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. What part of the ECMAScript specs talks about classes? > 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? No. That's the Function constructor (or Function function if you want to be really clever). > How is one supposed to know the difference? Different words? > This approach leads into chaos. Settle down. > > >> > 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. I'm afraid it is. > > >> 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'). > You don't seem to get that some of the language in the specification (which is aimed at implementors, not users) does not translate well into general parlance. For example, the DOM specifications (aimed at browser developers) refers to DOM properties as "attributes" in many cases. That doesn't mean we should all start calling attributse properties (or vice versa). I mean, look what happened to jQuery. :)
From: Thomas 'PointedEars' Lahn on 28 Jul 2010 09:03 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> 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. > > I doubt it. Doubt as much as you want, it's a fact: >> >> > 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). > > That one's obviously irrelevant. We'll see. >> JScript 7.0 and above are ECMAScript implementations, and they have >> classes. > > That's JScript.NET, which is an implementation of JScript. Utter nonsense. >> ActionScript 2.0 and above are ECMAScript implementations, and they have >> classes. > > You are reaching. Not at all. I am pointing out the flaw in your overgeneralization. > Do you really think I was including ActionScript in my (abbreviated) list? *You* have defined "JS" to be a synonym for "ECMAScript implementations" when referring to "JS" having no classes; ActionScript is one of them, and it certainly has classes. >> Do I need to go on? > > Certainly not. So you see the error of your way? >> >> > 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. > > What part of the ECMAScript specs talks about classes? Since you are asking, all sections of the proposal for ECMAScript Edition 4, of which JScript 7.0+ and other languages are implementations of (despite the fact that it never became a standard to date). But that is beside the point. A number of sections in ECMAScript Edition 3 and 5 talk about _instances_, which was what I was referring to. >> >> 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? > > No. That's the Function constructor (or Function function if you want > to be really clever). You may want to check on the use of either term. >> How is one supposed to know the difference? > > Different words? "Function object" is used with two meanings. This is to be avoided. Further, you cannot reasonably use "constructor" where there is no constructor, but still an inheritance-related name-based relationship between one object and another. >> This approach leads into chaos. > > Settle down. Think twice. >> >> > 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. > > I'm afraid it is. Stomping your foot will not help you to be convincing. >> >> 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'). > > You don't seem to get that some of the language in the specification > (which is aimed at implementors, not users) does not translate well > into general parlance. "General parlance" does not consist only of the part that you or the uninitiated accept of it. We have constructors, prototypes, native objects, built-in objects, host objects, variable objects, activation objects, global objects, aso. None of those would "translate well" to whatever imagined "general parlance" you are talking about. > For example, the DOM specifications [...] … are entirely irrelevant in this case. PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Thomas 'PointedEars' Lahn on 28 Jul 2010 09:07 Gregor Kofler wrote: > The square bracket notation is the preferred way to define array values. … since approximately 2000 CE, when JScript (5.0) started to support it, too. 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 28 Jul 2010 14:52 On Jul 28, 9:03 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > David Mark wrote: > > Thomas 'PointedEars' Lahn wrote: > >> 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. > > > I doubt it. > > Doubt as much as you want, it's a fact: > > >> >> > 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). > > > That one's obviously irrelevant. > > We'll see. I think we've already seen, haven't we? > > >> JScript 7.0 and above are ECMAScript implementations, and they have > >> classes. > > > That's JScript.NET, which is an implementation of JScript. > > Utter nonsense. Is it? Perhaps you mean the implementation itself? > > >> ActionScript 2.0 and above are ECMAScript implementations, and they have > >> classes. > > > You are reaching. > > Not at all. I am pointing out the flaw in your overgeneralization. I think you are wasting time. > > > Do you really think I was including ActionScript in my (abbreviated) list? > > *You* have defined "JS" to be a synonym for "ECMAScript implementations" > when referring to "JS" having no classes; ActionScript is one of them, and > it certainly has classes. > > >> Do I need to go on? > > > Certainly not. > > So you see the error of your way? No. > > > > >> >> > 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. > > > What part of the ECMAScript specs talks about classes? > > Since you are asking, all sections of the proposal for ECMAScript Edition 4, > of which JScript 7.0+ and other languages are implementations of (despite > the fact that it never became a standard to date). See above. It's a non-starter. > > But that is beside the point. A number of sections in ECMAScript Edition 3 > and 5 talk about _instances_, which was what I was referring to. As mentioned, those specification are aimed at *implementors*, just as the DOM specifications are aimed at *browser developers*. Do you understand that they necessarily use terminology that may not translate well to discussions among Web developers? > > >> >> 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? > > > No. That's the Function constructor (or Function function if you want > > to be really clever). > > You may want to check on the use of either term. What does that mean? Function is a constructor function. > > >> How is one supposed to know the difference? > > > Different words? > > "Function object" is used with two meanings. This is to be avoided. Exactly. That's why I don't use it to describe two different things. > Further, you cannot reasonably use "constructor" where there is no > constructor, but still an inheritance-related name-based relationship > between one object and another. I don't know what you mean by "there is no constructor" when we are clearly talking about the Function identifier, which refers to a constructor function. > > >> This approach leads into chaos. > > > Settle down. > > Think twice. I did. I'm still right. :) > > >> >> > 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. > > > I'm afraid it is. > > Stomping your foot will not help you to be convincing. Implying that because you are not convinced does not mean that others aren't. :) > > >> >> 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'). > > > You don't seem to get that some of the language in the specification > > (which is aimed at implementors, not users) does not translate well > > into general parlance. > > "General parlance" does not consist only of the part that you or the > uninitiated accept of it. I don't know what that means either. > We have constructors, prototypes, native objects, > built-in objects, host objects, variable objects, activation objects, global > objects, aso. Yes, those terms translate well as there is no ambiguity. And there is but one Global Object. > None of those would "translate well" to whatever imagined > "general parlance" you are talking about. Certainly they do. > > > For example, the DOM specifications [...] > > are entirely irrelevant in this case. > Your motion is denied, counselor. :)
First
|
Prev
|
Pages: 1 2 3 4 5 6 7 Prev: this.innerhtml Next: FAQ Topic - What books are recommended for javascript? (2010-07-21) |