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 20 May 2010 10:49 On May 20, 2:38 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 20.05.2010 15:24, Ry Nohryb wrote: > > > > > > > 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; > >> } > > > 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; > > } > > Oh, really? :O (Thanks, I know it. And the goal was to show exactly how > _assignment_ will change the memory block, but not only overloaded > "sugar" (which is known for all current speakers I hope) for accessing > properties of a structure via a pointer). > > > 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. > > I didn't get it. Type casting is relevant of course when we deal with C > in this case. But what do you mean in JS? Show me please an example. There's nothing to show, as there's no type-casting in JS :-) -- Jorge.
From: Dmitry A. Soshnikov on 20 May 2010 11:01 On 20.05.2010 18:49, Ry Nohryb wrote: > On May 20, 2:38 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > wrote: >> On 20.05.2010 15:24, Ry Nohryb wrote: >> >> >> >> >> >>> 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; >>>> } >> >>> 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; >>> } >> >> Oh, really? :O (Thanks, I know it. And the goal was to show exactly how >> _assignment_ will change the memory block, but not only overloaded >> "sugar" (which is known for all current speakers I hope) for accessing >> properties of a structure via a pointer). >> >>> 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. >> >> I didn't get it. Type casting is relevant of course when we deal with C >> in this case. But what do you mean in JS? Show me please an example. > > There's nothing to show, as there's no type-casting in JS :-) Then the question about type casting is closed and is irrelevant regarding to JS. I mean, there was no reason to mention it. Did I understand all correctly now? And drawing parallel with C's pointers (with the only mentioned above difference) and JS's strategy is still OK, yes. Dmitry.
From: John G Harris on 20 May 2010 11:18 On Wed, 19 May 2010 at 09:22:43, in comp.lang.javascript, Richard Cornford wrote: <snip> >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 <snip> Have you found the words in ECMA 262 that actually say that? If you have please tell me where as I haven't. It seems to be 'common knowledge' but not explicit. John -- John Harris
From: Ry Nohryb on 20 May 2010 11:21 On May 20, 5:01 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On 20.05.2010 18:49, Ry Nohryb wrote: > > > > > > > On May 20, 2:38 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > > wrote: > >> On 20.05.2010 15:24, Ry Nohryb wrote: > > >>> 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; > >>>> } > > >>> 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; > >>> } > > >> Oh, really? :O (Thanks, I know it. And the goal was to show exactly how > >> _assignment_ will change the memory block, but not only overloaded > >> "sugar" (which is known for all current speakers I hope) for accessing > >> properties of a structure via a pointer). > > >>> 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. > > >> I didn't get it. Type casting is relevant of course when we deal with C > >> in this case. But what do you mean in JS? Show me please an example. > > > There's nothing to show, as there's no type-casting in JS :-) > > Then the question about type casting is closed and is irrelevant > regarding to JS. I mean, there was no reason to mention it. Did I > understand all correctly now? Well, no. The ability to type cast, while unrelated to pointers, references and parameter passing mechanisms, is what allows C to shoehorn into a reference a different thing than what it was. Given that JS provides no such features (neither type-casting nor shoehorning a different type into a given reference), it's not fair to say that C pointers and/or its parameter passing mechanism allow a feature (what you call "one important difference") that JS lacks, because it's not a feature of the pointers/reference passing mechanism but that of the type casting C language feature. (Hmm, not even sure how well worded that is :-) > And drawing parallel with C's pointers (with the only mentioned above > difference) and JS's strategy is still OK, yes. It's fully equal, identical, if you leave aside type casting: there's not any difference at all. -- Jorge.
From: Richard Cornford on 20 May 2010 12:08
On May 20, 4:18 pm, John G Harris wrote: > On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote: > ><snip>>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 > > <snip> > > Have you found the words in ECMA 262 that actually say > that? If you have please tell me where as I haven't. It > seems to be 'common knowledge' but not explicit. The words that actually say what exactly? There are no words in the spec that say "can ... conclude", the ability to do that as a result of the observation is evidently a fact (as at least one person has done so). Richard. |