Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: RobG on 18 May 2010 19:57 On May 18, 10:56 pm, williamc <n...(a)nowhere.net> wrote: > On 5/18/2010 6:52 AM, Thomas 'PointedEars' Lahn wrote: > > RobG wrote: > > >> On May 18, 3:59 am, williamc <n...(a)nowhere.net> wrote: > >> [...] > >>> The second function creates the desired array of functions. Zakas: "The > >>> anonymous function has one argument, num, which is the number that the > >>> result function should return. Since function arguments are passed by > >>> value, the current value of i is copied into the argument num." > > >> More misdirection. They are always references, > > > What do you mean by "they" here? The values that are assigned by the calling function. > >> but the *value* might be a primitive or an object. > > > No, the value can be a primitive value or an object reference. To me, the values can be considered references for both (see below). > > You cannot access an object directly, you need a reference to it. > > As a result, there can be multiple references to the same object. [...] > > >> The the concept that "function arguments are passed by value" might be > >> kind of true if function arguments are always primitives, but they > >> aren't. > > > Zakas' premise is right here; you are not. Object references are values. > > See also > > <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Functions>, > > which was agreed on here. Yes, fair enough, if references are considered values. But that concept seems to be confusing, I find it simpler to think if it my way. > I wondered what people in c.l.j would say about the Zakas' point that > function arguments are always passed by value. He is right if references are considered values, which seems to be the majority opinion. > He kind of stresses it, > in the sense that he repeats it several times. I didn't really feel > comfortable with it at the time, and I still don't feel comfortable with > it. In most languages doesn't the concept of pass by value vs. pass by > reference refer to passing an independent copy vs. passing a reference > to the thing itself? I think in both cases their values are references because, to me, it is less confusing. As I posted eariler, given: var a = 5, b = a; You can think of a and b as refering to the same instance of 5. Since that instance can't be modified, the only way to change the value of a or b is to assign a new value. That is consistent with the equivalent scenerio using ojbects: var o = {}, p = a; Here p references the same object as o. If you assign a new value to either o or p, they now reference different objects or primitives depending on what was assigned. So the concept of reference and assignment is consistent regardless of whether an object or primitve is assigned. Special behaviour is now kept to objects: when an object is modifed, everything that references it "sees" the modifications. You can't modify primitives, so they don't have the same behaviour: o.property1 = 'one'; Here a value is assigned to a property of the object referenced by o, i.e. the object was modified, no new value was assigned to o. So o and p still reference the same object and: alert( p.property1 ); // shows 'p' Anyhow, that's my way of understanding it. > I have a "something I'm missing here" feeling... > > obj = { > propX: "foo" > }; > num = 27; > > function test(argNum, argObj) { > argNum = 28; > argObj.propX = "bar"; > } > > test(num, obj); > > console.log(num); // still 27 Yes, because a new value was assigned to argNum, not to num. > console.log(obj.propX); // "bar", Because no new value was assigned to either obj or argObj, the object they reference was modified (something that is impossible with primitives). David shows what happens if you assign a new value to one of them, which is consisent whether you assign a primitve, object, null, whatever. > so why isn't this called a pass by reference? I don't think of it as "passing" but assigning. The variables in the parameter list are assigned values depending on what is in the calling parameter list. > In the link Thomas cited it says... > > "The parameters of a function call are the function's arguments. > Arguments are passed to functions by value. If the function changes the > value of an argument, this change is not reflected globally or in the > calling function. However, object references are values, too, and they > are special: if the function changes the referred object's properties, > that change is visible outside the function, ... " > > So, I guess I'm having a hard time with the "they are special". Wouldn't > this specialness simply be called a pass by reference in most languages? Which is why I limit the specialness to objects, not assignment. I hope I've helped, not confused. :-) -- Rob
From: Thomas 'PointedEars' Lahn on 18 May 2010 20:43 RobG wrote: > williamc wrote: >> Thomas 'PointedEars' Lahn wrote: >> > RobG wrote: >> >> williamc wrote: >> >> [...] >> >>> The second function creates the desired array of functions. Zakas: >> >>> "The anonymous function has one argument, num, which is the number >> >>> that the result function should return. Since function arguments are >> >>> passed by value, the current value of i is copied into the argument >> >>> num." >> >> More misdirection. They are always references, >> > What do you mean by "they" here? > > The values that are assigned by the calling function. How can *you* know for sure what *he* meant? >> >> but the *value* might be a primitive or an object. >> > >> > No, the value can be a primitive value or an object reference. > > To me, the values can be considered references for both (see below). You are wrong. >> >> The the concept that "function arguments are passed by value" might be >> >> kind of true if function arguments are always primitives, but they >> >> aren't. >> > >> > Zakas' premise is right here; you are not. Object references are >> > values. See also >> > <https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Functions>, >> > which was agreed on here. > > Yes, fair enough, if references are considered values. But that > concept seems to be confusing, I find it simpler to think if it my > way. > >> I wondered what people in c.l.j would say about the Zakas' point that >> function arguments are always passed by value. > > He is right if references are considered values, which seems to be the > majority opinion. That is not an opinion, it is a fact. RTFM. >> He kind of stresses it, in the sense that he repeats it several times. I >> didn't really feel comfortable with it at the time, and I still don't >> feel comfortable with it. In most languages doesn't the concept of pass >> by value vs. pass by reference refer to passing an independent copy vs. >> passing a reference to the thing itself? > > I think in both cases their values are references because, to me, it > is less confusing. As I posted eariler, given: > > var a = 5, > b = a; > > You can think of a and b as refering to the same instance of 5. But you should not. While Smalltalk undoubtedly is an ancestor of JavaScript/ECMAScript, by contrast `5' is _not_ an object in ECMAScript implementations (it is only being implicitly converted to a Number instance sometimes). So, in your words, `b' "refers" to _another_ `5' than `a'. Indeed, the variables `a' and `b' would very likely be implemented as two pointers pointing to different heap addresses. > Since that instance can't be modified, the only way to change the value of > a or b is to assign a new value. That is consistent with the equivalent > scenerio using ojbects: > > var o = {}, > p = a; > > Here p references the same object as o. If you assigned the value of `o', and not `a'. > If you assign a new value to either o or p, they now reference different > objects Only if the new value is an object reference. > or primitives Primitives are _not_ being referred to (as references are understood in these languages.) > depending on what was assigned. So the concept of reference and > assignment is consistent regardless of whether an object or primitve > is assigned. No, it is not. > Anyhow, that's my way of understanding it. Well, misconceptions are quite common in this field. 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 21:14 On 18/05/10 15:05, David Mark wrote: > 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 I think that's a perfect illustration. It's all you need to see to understand that there is no pass-by-reference in JS. Incidentally, that's also the way it works in Java, and Java is also the source of the expression "reference types" that has been thrown around here a couple of times. -- stefan
From: Garrett Smith on 18 May 2010 21:24 Stefan Weiss wrote: > On 18/05/10 15:05, David Mark wrote: >> 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 > > I think that's a perfect illustration. It's all you need to see to > understand that there is no pass-by-reference in JS. Incidentally, > that's also the way it works in Java, and Java is also the source of the > expression "reference types" that has been thrown around here a couple > of times. The same behavior is seen in Java, however, Java's "reference types" has different meaning that Reference type in ECMAScript. Java Reference Types, from JLS, 3rd Edition, Chapter 4: | The reference types (ยง4.3) are class types, interface types, and | array types. http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html ECMAScript Reference Type, from ECMAScript Edition 3, s 8.7 | The internal Reference type is not a language data type. It is defined | by this specification purely for expository purposes. An | implementation of ECMAScript must behave as if it produced and | operated upon references in the manner described here. However, a | value of type Reference is used only as an intermediate result of | expression evaluation and cannot be stored as the value of a variable | or property. Elsewhere: http://dmitrysoshnikov.com/ecmascript/chapter-8-evaluation-strategy/ -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: RobG on 18 May 2010 22:33
On May 19, 10:43 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > RobG wrote: > > williamc wrote: > >> Thomas 'PointedEars' Lahn wrote: > >> > RobG wrote: > >> >> williamc wrote: > >> >> [...] > >> >>> The second function creates the desired array of functions. Zakas: > >> >>> "The anonymous function has one argument, num, which is the number > >> >>> that the result function should return. Since function arguments are > >> >>> passed by value, the current value of i is copied into the argument > >> >>> num." > >> >> More misdirection. They are always references, > >> > What do you mean by "they" here? > > > The values that are assigned by the calling function. > > How can *you* know for sure what *he* meant? You asked what *I* meant, I've explained that. [...] > > I think in both cases their values are references because, to me, it > > is less confusing. As I posted eariler, given: > > > var a = 5, > > b = a; > > > You can think of a and b as refering to the same instance of 5. > > But you should not. While Smalltalk undoubtedly is an ancestor of > JavaScript/ECMAScript, by contrast `5' is _not_ an object in ECMAScript > implementations (it is only being implicitly converted to a Number instance > sometimes). > > So, in your words, `b' "refers" to _another_ `5' than `a'. No, in my words, 'b' and 'a' refer to the same '5'. Since that '5' can't be modified, the value of 'b' can only be changed by assigning a new value, even if it's another '5'. > Indeed, the > variables `a' and `b' would very likely be implemented as two pointers > pointing to different heap addresses. Maybe, but implementation details are irrelevant. > > Since that instance can't be modified, the only way to change the value of > > a or b is to assign a new value. That is consistent with the equivalent > > scenerio using ojbects: > > > var o = {}, > > p = a; > > > Here p references the same object as o. > > If you assigned the value of `o', and not `a'. Yes, a typo. [...] > > Anyhow, that's my way of understanding it. > > Well, misconceptions are quite common in this field. Apparently - I'll keep this one to myself. BTW, do you have a link to where it was discussed here previously? -- Rob |