Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: Ry Nohryb on 19 May 2010 20:30 On May 19, 3:15 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > > (...) If it was a pointer, which it is not, it would work like > call-by-reference (...) That's not true either. Not in C. To begin with, there's no such thing as "call by reference" in C. But there's "pass by reference", as in JS. See: http://google.com/search?q=pass+by+reference+in+C The very first link would do: http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlcpp8a.doc/language/ref/cplr233.htm Note, however, that in C, there's a way to avoid the need to apply the & operator to the object in order to get it passed by reference (as in JS), so, instead of the usual: $cat a.c #include <stdio.h> typedef struct objeto { int aProperty; } tipo; void test (tipo* o) { o->aProperty = 27; } int main (void) { tipo o; test(&o); printf ("%d\n", o.aProperty); return 0; } $ gcc a.c $ ./a.out --> 27 The call can be written as test(o) [ NOTE: that looks exactly like JS, yet more funny: it BEHAVES exactly like JS ] just by declaring the struct as a one element array of structs: $ cat b.c #include <stdio.h> typedef struct objeto { int aProperty; } tipo [1]; void test (tipo o) { o->aProperty = 27; } int main (void) { tipo o; test(o); printf ("%d\n", o->aProperty); return 0; } $ gcc b.c $ ./b.out --> 27 -- Jorge.
From: RobG on 19 May 2010 23:33 On May 19, 10:37 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > RobG wrote: > > Thomas 'PointedEars' Lahn wrote: > >> RobG wrote: [...] > > [...] > >> > 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'. > > That's nonsense. Have you subscribed to VK101 by now? There is no imperative to copy the value to b. The value '5' can't be modified, so there is no chance that assigning a new value to a will result in a change of the value of b. It seems an implementation may, in the interests of efficiency, make a and b the same primitive. I tried Jorge's VB test in IE and Firefox (code below). One function created 1,000 global variables with the same 375KB of text assigned to each. A second function assigned a unique string to each by slightly modifying its original string. Results were: In IE 6: Start: 609MB Load page in new instance of IE: 617MB Create 1,000 variables: 1,367MB Modify them: 1,367MB In Firefox 3.6 Start: 612MB Load page in new tab: 615MB Create 1,000 variables: 617MB Modify them: 1,380MB I think the above shows that IE creates 1,000 copies if the same string initially, consuming about an extra 650MB of memory. Assigning new values of the same size doesn't use any extra memory. However, Firefox's much lower initial memory use indicates that it creates 1,000 references to the same string. It is only when a new string is assigned to each variable that it creates 1,000 separate strings and consumes and extra 760MB or so of memory. > >> 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. > > No, implementation details are at the core of the issue. So if implementation details matter (and you seem to think they do), then you can argue on a per implementation basis as to whether my original example above (var a=5, b=a; etc.) results in a reference to the same primitive or a new copy being created. I don't think implementation details matter, my opinion is purely a theoretical exercise to create a system for understanding behaviour that is consistent with the specification and observation. My idea of "references" to primitives seems to fit with Firefox, your idea of each assignment creating a new copy, always, fits with IE. > >> > 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? > > I might have a Message-ID. I would appreciate it if you can find it. Test code: <script type="text/javascript"> // Text seed var txt = "..."; // Slab of text, say 3,500 characters // bigTxt will be about 100 times bigger than txt var bigTxt = (function() { for (var i=100, s=''; i; i--) { s += txt; } return s; })(); // Create a bunch of global vars, assign bigTxt function createVars() { for (var i=1000; i; i--) { window['a' + i] = bigTxt; } }; // Modify created globals function modifyVars() { for (var i=1000, t; i; i--) { t = window['a' + i] window['a' + i] = i + ' ' + t; } } </script> <button onclick="alert(a1);">Show a1</button> <button onclick="createVars()">Create vars</button> <button onclick="modifyVars()">Modify vars</button> -- Rob
From: Lasse Reichstein Nielsen on 20 May 2010 01:21 Ry Nohryb <jorge(a)jorgechamorro.com> writes: > On May 19, 10:35�pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > wrote: >> No, that is _not_ how pass-by-reference (better: call-by-reference) is >> defined. �And therefore call-by-reference simply does not happen in >> ECMAScript implementations (to date). > > You can repeat that as many times as you want, but in JS objects are > passed by reference exactly as in C. It's just that most script- > kiddies are too young -and lacking in C- to comprehend it. C is a bad example since it doesn't have reference parameters at all (nor objects, for that matter). The behavior in javascript does match the passing of an object reference in C++. However, you can't pass a variable in javascript, only an object reference, which is why it isn't what is traditionally considered call-by-reference. It's just that objects aren't denotable values in Javascript, nor expressible cvalues for that matter, only object references are. /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Dmitry A. Soshnikov on 20 May 2010 05:05 On 20.05.2010 9:21, Lasse Reichstein Nielsen wrote: > Ry Nohryb<jorge(a)jorgechamorro.com> writes: > >> On May 19, 10:35 pm, Thomas 'PointedEars' Lahn<PointedE...(a)web.de> >> wrote: > >>> No, that is _not_ how pass-by-reference (better: call-by-reference) is >>> defined. And therefore call-by-reference simply does not happen in >>> ECMAScript implementations (to date). >> >> You can repeat that as many times as you want, but in JS objects are >> passed by reference exactly as in C. It's just that most script- >> kiddies are too young -and lacking in C- to comprehend it. > > > C is a bad example since it doesn't have reference parameters at all > (nor objects, for that matter). > C's example with passing a pointer's value (an address) -- is a good example to show how JS works. If to consider C's abstraction level and its "by-pointer" strategy which is called a "by-reference" there (because, there is no "by-reference" in meaning of e.g. C++'s "by-reference", but still a pointer's value is a "reference" (to memory block), an address (of a memory block)) -- then it is normally possible to call it a "by-reference" strategy and it's no a crime. But, repeat, meaning only C's abstraction level and its local terminology. And still the value of a formal parameter will be a copy of an address (e.g. a reference). So from this viewpoint, Ry Nohryb is right. That exactly how JS works and it can be compared with C's pointers (but with one important difference -- it is impossible to dereference this pointer and change the value to which it points). Taking into account that for C's abstraction level and it terminology, he can easily name is as a "by-reference" and will be right. I even thinking of an additional paragraph to my article (http://bit.ly/dcMUTr) to the end, in "Terminology versions", saying something: "But is it a crime if in everyday talks you name it as "by-reference" meaning that you can change an object's property values via a formal parameter? No, but keep in mind, that it can be incorrectly treating of considered about "by-reference" strategy when you can change the object itself assigning a new value to the formal parameter". But, I didn't add it yet, still thinking. If to consider abstraction level of e.g. C++, then there is separated syntactic sugar of "by-reference" and there the "by-reference" of C's abstraction has another meaning. _Alternative_ naming for "old" "by-pointer" (which is named a "by-reference" in C) can be "by-sharing". I.e. passing by a pointer's value and this value is _shared_ between all _name bindings_. Is it so in ES? Absolutely. This terminology is used in other languages; I used it also in my article to show an exact distinction between "by-value" and "by-reference". And there is a new sugar -- "by reference" which means strictly speaking a "constant pointer which is not needed to be dereferenced to changed the value to which this pointer refers". In general, this "reference sugar" is implemented as a constant pointer and transforms to it on preprocessing/compilation stage (although, it can be dependent on implementation). So from the C++'s abstraction level, it is already incorrect to name JS's strategy as "by-reference", since, repeat, there is additional "by-reference" "sugar". So, C++ fits better to exactly separate - "by-reference"; - "by-pointer" == "by-sharing" == "by value, where value is a pointer"; - "by-value". > The behavior in javascript does match the passing of an object > reference in C++. Yes, and this is exactly what happens in JS (when we have a pointer as a formal parameter and pass a reference). But, I should repeat, that we're considering some _implementation_ level and trying to speak with terminology and abstractions of _that implementation level_. Nevertheless, if to talk in ECMA-262 abstractions, there is only "values" and what are these "values" isn't so essential. Because it's leaved for implemenations. And an implementation can be written on JS itself which has _its own terminology and abstractions_. > However, you can't pass a variable in javascript, > only an object reference, which is why it isn't what is traditionally > considered call-by-reference. > What do you mean "pass a variable"? The C++'s "reference" sugar, when a formal parameter's name becomes an alias? If yes, then OK. Dmitry.
From: Ry Nohryb on 20 May 2010 05:47
On May 20, 11:05 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > (...) > So from this viewpoint, Ry Nohryb is right. That exactly how JS works > and it can be compared with C's pointers (but with one important > difference -- it is impossible to dereference this pointer and change > the value to which it points). (...) No, neither in C: as I tried to explain to Pointy, in C you would *not* be able to "change the value to which it points" without resorting to type casting: IOW: exactly as in JS: a reference to an object can't be made to point to e.g. an array or a number. But type casting is a different feature that belongs to a separate chapter. -- Jorge. |