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 08:38 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. Dmitry.
From: Richard Cornford on 20 May 2010 09:08 On May 20, 12:54 pm, Ry Nohryb wrote: > On May 20, 1:02 pm, Richard Cornford 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" :-) <snip> Cheating isn't even a consideration if you are not breaking any of the rules in the first place. The broader problem here is coming up with some (preferably simple and concise) formulation that will inform people who are not (sufficiently) familiar with what javascript does (with regard to function/method calls) about what they can expect (and why). To that end there is an appeal in explanations that draw parallels with the behaviour in other languages (though obviously that is of limited value for total newcomers (or even those unfamiliar with the languages in question (or sufficiently similar languages))). I have read, and/or been involved in, numerous discussions of the terminology that gets applied to these explanations, such as "pass-by- value", pass-by-reference", "pointer", etc. Unfortunately, there appear to be as many valid reasons for using each as valid reasons for their being inapplicable to javascript (or in extreme cases too esoteric/obscure to be usefully employed in explaining javascript). So round and round the arguments go. It makes me think that a different approach might be better. Possibly an approach that does not stray too far from ECMA 262; where no real attempt is made to resolve "value" and an object can be (or is) just a "value". That will take some thinking about, and probably two or three attempts to get right. Richard.
From: Johannes Baagoe on 20 May 2010 09:13 Richard Cornford : > I have read, and/or been involved in, numerous discussions of the > terminology that gets applied to these explanations, such as "pass-by- > value", pass-by-reference", "pointer", etc. Unfortunately, there appear > to be as many valid reasons for using each as valid reasons for their > being inapplicable to javascript (or in extreme cases too > esoteric/obscure to be usefully employed in explaining javascript). So > round and round the arguments go. I found Liskov's "call-by-sharing" terminology very handy. http://en.wikipedia.org/wiki/Evaluation_strategy -- Johannes
From: Ry Nohryb on 20 May 2010 10:30 On May 20, 3:08 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk> wrote: > On May 20, 12:54 pm, Ry Nohryb wrote:> On May 20, 1:02 pm, Richard Cornford 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" :-) > > <snip> > > Cheating isn't even a consideration if you are not breaking any of the > rules in the first place. > > The broader problem here is coming up with some (preferably simple and > concise) formulation that will inform people who are not > (sufficiently) familiar with what javascript does (with regard to > function/method calls) about what they can expect (and why). To that > end there is an appeal in explanations that draw parallels with the > behaviour in other languages (though obviously that is of limited > value for total newcomers (or even those unfamiliar with the languages > in question (or sufficiently similar languages))). > > I have read, and/or been involved in, numerous discussions of the > terminology that gets applied to these explanations, such as "pass-by- > value", pass-by-reference", "pointer", etc. Unfortunately, there > appear to be as many valid reasons for using each as valid reasons for > their being inapplicable to javascript (or in extreme cases too > esoteric/obscure to be usefully employed in explaining javascript). > So round and round the arguments go. > > It makes me think that a different approach might be better. Possibly > an approach that does not stray too far from ECMA 262; where no real > attempt is made to resolve "value" and an object can be (or is) just a > "value". That will take some thinking about, and probably two or three > attempts to get right. No doubt. What I'm 100% against is the new, almost fundamentalist, revisionist and disrespectful attempt at re-definition of the meaning of the simple and well established over 30 years ago and commonly used term "pass-by-reference", by young newbie wannabe programmers (in funny t- shirts and wearing colorful horn-rimmed eyeglasses), obviously due to their *total*ignorance* of not only the C language but the *history* and the previous *well*established*long-standing*terminology*. Grrr. -- Jorge.
From: Ry Nohryb on 20 May 2010 10:45
On May 20, 3:13 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Richard Cornford : > > > I have read, and/or been involved in, numerous discussions of the > > terminology that gets applied to these explanations, such as "pass-by- > > value", pass-by-reference", "pointer", etc. Unfortunately, there appear > > to be as many valid reasons for using each as valid reasons for their > > being inapplicable to javascript (or in extreme cases too > > esoteric/obscure to be usefully employed in explaining javascript). So > > round and round the arguments go. > > I found Liskov's "call-by-sharing" terminology very handy. > http://en.wikipedia.org/wiki/Evaluation_strategy <quote> However, the term "call by sharing" is not in common use; the terminology is inconsistent across different sources. For example, in the Java community, they say that Java is pass-by-value, whereas in the Ruby community, they say that Ruby is pass-by-reference, even though the two languages exhibit the same semantics. </quote> C: 1972, Java, Ruby, JS, PHP: 1995. Gimme a break. -- Jorge. |