Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: williamc on 18 May 2010 10:53 On 5/18/2010 10:34 AM, Thomas 'PointedEars' Lahn wrote: > williamc wrote: > >> David Mark wrote: >>> No. The value passed is a reference to an object. That might sound >>> like a contradiction in terms, but consider:- >>> >>> function test(o) { >>> o = null; >>> } >>> >>> var p = {}; >>> test(p); >>> window.alert(p); // Not null >> >> Yikes! Well, that's certainly a good example, as I would have expected p >> to be null after the function call. But I can't say that I've succeeded >> in understanding why it isn't. > > As `o' is but a variable (sort of) that is assigned a value, a reference to > an object, as execution enters the context of the function [ES3/5, 10.4] -- > > p > || > ref ---> [object Object] > || > o > > -- then changing the value of the (local) "variable" in the function does > not change the object, of course: > > p > || > ref ---> [object Object] > > o = null > > That is where object references are special. As long as a property (here: > of the function context's Variable Object) stores a reference value, you can > use that property to change the referred object's properties. > >> So, the right way to think about is the object "supplies the value to >> the function"? > > No, `p' did not store the object in the first place; it only stored the > reference (value) to it. As does `q' below: > > var p = {}; > > /* > * p > * || > * ref ---> [object Object = {}] > */ > > var q = p; > > /* > * p > * || > * ref ---> [object Object = {}] > * || > * q > */ > > q.a = 42; > > /* > * p > * || > * ref ---> [object Object = {a: 42}] > * || > * q > */ > > /* 42 */ > p.a; > > BTW, it's the same in Java and other OOPLs. > > You want to fix your `From' header. > > > HTH > > PointedEars OK, thanks. I'll ponder this... Fix my 'From' header in the sense of supplying a valid e-mail address? --williamc
From: Thomas 'PointedEars' Lahn on 18 May 2010 11:14 williamc wrote: > [...] Fix my 'From' header in the sense of supplying a valid e-mail > address? In the sense of supplying an e-mail address in the first place. You have something there that looks like one but is not, thereby bothering potential respondents with bounces and 216.8.179.23 with futile connection attempts. And please trim your quotes to the relevant minimum next time. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on 18 May 2010 11:33 Stefan Weiss wrote: > Thomas 'PointedEars' Lahn wrote: >> Stefan Weiss wrote: >>> Eleandor wrote: >>>> Person = (function() { >>>> return function() { >>>> var self = this; >>> ... >>> >>> Minor nitpick: self is not a good variable name in browser scripting; >>> it's usually an alias for the window object. It won't cause a problem in >>> your example, but it could confuse people who see a call to >>> "self.shout()" before they see the assignment above. >> >> It is not "usually an alias for the window object", it is a property of >> Window instances or their prototype to refer to the instance. A Window >> instance's prototype may be in the prototype chain of the ECMAScript >> Global Object (this is the case with client-side JavaScript 1.8.2 in >> Gecko 1.9.2.3). > > Very verbose, but technically correct. That doesn't affect the point I'm > trying to make, however: in browser scripting, the "self" identifier > usually already refers to _something_ - Usually, granted, but I would not count on that it always does. > just like "document" and "window" do. You're free to assign something else > to them, This reads like the built-in value would be overwritten then; it is not. > but this can cause confusion for readers. But that is not a good argument, see below. *Anything* can cause confusion for the reader, particular uninitiated ones. 100% of the technical discussions and proper code posted here (like, closures by called function expressions, Array initialization with leading comma, `~+s', `new Date() - new Date(2000, 0, 1)') would confuse at least someone. >> Since to my knowledge it is unnecessary to access the `self' property of >> Window instances, I can see no cause for confusion here. Indeed, the >> declaration follows the pattern of several other OOPLs, including most >> notably, IIUC, Smalltalk which influenced the prototype-based Self >> programming language (where you can omit `self') which influenced >> JavaScript (unfortunately, Brendan Eich apparently did not see the >> importance of the `self' keyword in JavaScript's predecessors). > > Neither do I. As a reference to the current context (or instance), > "self" feels more natural to me than "that" or "me" (some conventional > alternatives), but reusing it has the potential for confusion and should > therefore be avoided, IMHO. You are confusing cause and effect, though. Wouldn't it be great if you could forget about the var that = this; or var self = this; etc. and simply write only: > For example: I didn't read the original code posted by Eleandor, mostly > because of the formatting. The first thing I saw was Matt's example: > > elm.onclick = (function(inner_i) { > return function() { > self.shout(inner_i); > } > })(i); > > I wondered why he would call shout() as self.shout(), so I checked > whether self had been redefined (it was), but from that snippet alone, > it looked like shout() was a global function. You have learned something, then. That confusion can only occur because someone (I'm afraid, Brendan Eich, too) had the (not-so-)great idea to provide Window instances with a self-referring `self' property and put a Window instance in the prototype chain of the Global Object (or before the Global Object in the scope chain, depends on the implementation), to mix language and browser object model (that was fixed in JavaScript 1.4, but it was too late by then). So that people became accustomed to writing `alert' when they meant `window.alert', and seeing `window.self' when someone was writing only `self'. And Netscape's competitors copied that mistake in order to be compatible. That does not mean this misconception needs to be catered by not declaring a `self' variable in browser scripting. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Stefan Weiss on 18 May 2010 12:33 On 18/05/10 17:33, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: >> As a reference to the current context (or instance), >> "self" feels more natural to me than "that" or "me" (some conventional >> alternatives), but reusing it has the potential for confusion and should >> therefore be avoided, IMHO. > > You are confusing cause and effect, though. Wouldn't it be great if you > could forget about the > > var that = this; > > or > > var self = this; > > etc. and simply write only: [ self.shout(inner_i); ] It would sure be convenient, but I doubt there's a way for a JS engine to determine which of the (potentially many) nested "this values" the "self" identifier should point to. >> I wondered why he would call shout() as self.shout(), so I checked >> whether self had been redefined (it was), but from that snippet alone, >> it looked like shout() was a global function. > > You have learned something, then. Only that we're not confused by the same things. :) "self.shout" looked ambiguous to me, when I saw it, so I stand by my warning about a "potentially confusing" construct, even if the confusion is apperently not universal. > That confusion can only occur because > someone (I'm afraid, Brendan Eich, too) had the (not-so-)great idea to > provide Window instances with a self-referring `self' property and put a > Window instance in the prototype chain of the Global Object (or before the > Global Object in the scope chain, depends on the implementation), to mix > language and browser object model (that was fixed in JavaScript 1.4, but > it was too late by then). I agree, it's unfortunate. Hindsight is always 20/20... > So that people became accustomed to writing `alert' when they meant > `window.alert', and seeing `window.self' when someone was writing only > `self'. And Netscape's competitors copied that mistake in order to be > compatible. > > That does not mean this misconception needs to be catered by not declaring > a `self' variable in browser scripting. You could apply the same argument to any other property of the window object. Why not redefine alert, for example? I'm not calling window.alert in my script, so I might as well reuse the name. But I don't - and the reason is, as before, to avoid confusion for others. -- stefan
From: Thomas 'PointedEars' Lahn on 18 May 2010 19:52
Stefan Weiss wrote: > Thomas 'PointedEars' Lahn wrote: >> Stefan Weiss wrote: >>> As a reference to the current context (or instance), >>> "self" feels more natural to me than "that" or "me" (some conventional >>> alternatives), but reusing it has the potential for confusion and should >>> therefore be avoided, IMHO. >> >> You are confusing cause and effect, though. Wouldn't it be great if you >> could forget about the >> >> var that = this; >> >> or >> >> var self = this; >> >> etc. and simply write only: > [ self.shout(inner_i); ] > > It would sure be convenient, but I doubt there's a way for a JS engine > to determine which of the (potentially many) nested "this values" the > "self" identifier should point to. A definition can be found. (Didn't ES5 specify something similar?) >> So that people became accustomed to writing `alert' when they meant >> `window.alert', and seeing `window.self' when someone was writing only >> `self'. And Netscape's competitors copied that mistake in order to be >> compatible. >> >> That does not mean this misconception needs to be catered by not >> declaring a `self' variable in browser scripting. > > You could apply the same argument to any other property of the window > object. Why not redefine alert, for example? I'm not calling > window.alert in my script, so I might as well reuse the name. But I > don't - and the reason is, as before, to avoid confusion for others. Then we have to agree to disagree here. If I always needed to write code so that it could not possibly stir some neophyte's confusion, so that it catered and helped cultivating their many misconceptions instead, I would not only be writing much less efficient code, but also my development process itself would be much less efficient then. And I would deprive them of the singular opportunity that is being granted to me, to learn about creating something better than the usual junk out there, just by reading other's code and trying to understand it. 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.) |