Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: Dmitry A. Soshnikov on 20 May 2010 06:23 On 20.05.2010 13:47, Ry Nohryb wrote: > 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. Wait the second, how a type casting is relevant with that we can dereference a pointer (of our type of course - a structure in the example below) and assign a new value for the memory block? I.e.: #include <stdio.h> struct Object { int x; int y; }; void foo(struct Object* oRefCopy) { struct Object o2; o2.x = 100; o2.y = 200; *oRefCopy = o2; } int main() { struct Object o; o.x = 10; o.y = 20; foo(&o); printf("o.x = %d, o.y = %d", o.x, o.y); // 100, 200 return 0; } Dmitry.
From: Richard Cornford on 20 May 2010 07:02 On May 19, 6:06 pm, Ry Nohryb wrote: > On May 19, 6:22 pm, Richard Cornford wrote: >> On May 19, 4:54 pm, Ry Nohryb wrote: >><snip> > >>> WRT objects, you're always passing references, by copy, >>> but references, unlike when passing primitive values. > >> How can you tell? Specifically, how can you tall that >> primitives are not implemented as structures somewhere >> in memory and that the values assigned to object >> properties/valuables are not references to those structures; >> that copying a primitive 'value' from one variable to >> another does not actually involve copying a reference? > >> The thing is that you cannot tell. Javascript offers no >> operators that will allow you to modify a primitive, so >> while you can observe the modification to an object and >> conclude that there must be some 'referencing' mechanism >> that has all values that are objects 'referring' to the >> single object the inability to do the same test on the >> primitives does not excused the possibility that exactly >> the same implementation mechanism has been applied to >> them. > > Well, yes, you're right. The observable behaviour must be > as if they were passed by copy, I would have to disagree with that. The specified behaviour does not include anything that you could observe in order to make the differentiation. > and it is. Doesn't your following observation show that "is" should be replaced by "may or may not be"? > But then, it's observable as well that in V8 at least > the strings are not passed by copy, because, if you copy How do you "copy" a string in javascript? You can assign a string primitive values that is already assigned to some property/variable to another property/variable but that only results in two properties/ variables having the same "value". > a 100MB string to 8 > different vars, V8 does *not* use 800 MB, Fine, there is no reason why it should. > even though > looking at the specs they should have been duplicated. That has never been my reading of the spec. When a specification is couched in terms of required behaviour, if there should be a copy then there should also be some means of observing that there was a copy (from within the language). > It's when you add a single char to them that they are > duplicated. You cannot "add a single char" to a string primitive value, because the language does not include any operators, methods or syntax that are capable of modifying primitive values. An expression such as - st += 'x'; -(assuming st to have a value that is a string primitive) does not modify the value held by st, it replaces it with a new value that is the string primitive containing all the characters that were in the string that was the value of st with an 'x' value concatenated to the end. This is the creation of a new string primitive not a modification to an existing one. Increased memory use would be difficult to avoid when new values are being created. Richard.
From: Ry Nohryb on 20 May 2010 07:24 On May 20, 12:23 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 20.05.2010 13:47, Ry Nohryb wrote: > > > 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. > > Wait the second, how a type casting is relevant with that we can > dereference a pointer (of our type of course - a structure in the > example below) and assign a new value for the memory block? > > I.e.: > > #include <stdio.h> > > struct Object { > int x; > int y; > > }; > > void foo (struct Object* oRefCopy) { > struct Object o2; > o2.x = 100; > o2.y = 200; > *oRefCopy = o2; > } > > int main (void) { > struct Object o; > o.x = 10; > o.y = 20; > foo(&o); > printf("o.x = %d, o.y = %d", o.x, o.y); // 100, 200 > return 0; > } Well, that does not illustrate a way to assign anything "different" because both objects are of exactly the same type and therefore what you're doing here is just a convoluted (and inefficient, btw) way of doing this: void foo (struct Object* oRefCopy) { oRefCopy->x = 100; oRefCopy->y = 200; } And, unless you resort to type casting, you *won't* be able put anything other (different) than exactly an "Object" type into o, just as happens in JS: a reference to an object (in JS) will always point to that object: you can modify it, but you can't make it be anything ! == than the object that it is. -- Jorge.
From: Ry Nohryb on 20 May 2010 07:54 On May 20, 1:02 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > (...) So the the semantics of pass-by-value ("by-copy") do *not* necessarily imply a copy. What can I say ? Brilliant ! You're right, afaics. There's another way of putting it: (*) "you can cheat if you don't get caught" :-) (*)http://www.mail-archive.com/es-discuss(a)mozilla.org/msg00072.html -- Jorge.
From: Ry Nohryb on 20 May 2010 08:01
On May 20, 7:21 am, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > > C is a bad example since it doesn't have reference parameters at all > (nor objects, for that matter). C is a perfect example imo because it's the grandfather of JS, and because I'm trying hopelessly to point out that the terminology used for over 30 years in C wrt passing by reference is applicable to JS as well. -- Jorge. |