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 12:54 On May 20, 6:34 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Ry Nohryb : > > > Johannes Baagoe : > >> 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. > > Well, the "call-by-reference" vs. "call-by-value" terminology is > even older, it comes from the great FORTRAN vs. Algol wars. (In early > versions of FORTRAN, one could actually change the value of constants, > by something like CALL INCREMENT(1) if I remember rightly.) > > Most modern languages use neither FORTRAN's pure call-by-reference, > nor pure call-by-value, where even huge data structures are copied > entirely, like in Algol and its successors like Pascal (unless the formal > parameter is preceded by the `var` keyword). > > What they do use deserves a name, IMHO, since it is a very important > point to understand. "Call by sharing" may not be the best possible > wording, but it was proposed by a lady with a Turing award. I think > it may serve until someone comes up with a better idea. It's ok to call it call-by-sharing but it's not ok to say that objects aren't being passed by reference. -- Jorge
From: Lasse Reichstein Nielsen on 20 May 2010 14:19 Ry Nohryb <jorge(a)jorgechamorro.com> writes: > On May 20, 6:09�pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> > wrote: >> >> I sure hope you can't since that's probably how all implementations >> handle strings (and some handle large numbers that way too). :) > > Does a large number occupy any more than a small one ? Not just the plain size, but some implementations have optimizations for small *integers*, with a fallback to a full double value for the values that can't be optimized. See, e.g., http://trac.webkit.org/browser/trunk/JavaScriptCore/runtime/JSImmediate.h#L75 http://code.google.com/p/v8/source/browse/trunk/src/objects.h#717 /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Dr J R Stockton on 20 May 2010 12:30 In comp.lang.javascript message <timstreater-9A1608.13415819052010(a)news. individual.net>, Wed, 19 May 2010 13:41:58, Tim Streater <timstreater(a)waitrose.com> posted: > >Which is why: > > function test (o) { o = null; } > >does *not* change p, whereas: > > function test (o) { o.j= "Simpson"; } > >*does* change the *object* that p points at. While test is running, >there are two pointers to the object, and only one before and after (or >at some point after, possibly). > It does not change the object. It does change the contents of the object. -- (c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links; Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc. No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
From: Eleandor on 20 May 2010 21:15 Wow, I had no idea this would receive so many replies... Even though most of them are irrelevant to my question. First some apologies: I always use \t for indendation in my editor, so I'm sorry for not following the expected indendation rules as I wasn't aware of them. Neither was I aware that "self" is an alias for "window". Won't use it again, clearly it causes too much confusion. For all I care though, I don't see much use for "self"... Sorry for omitting the DOCTYPE & title elements. It's only a testpage and I didn't think it would cause any harm in a browser like FF or chrome. Another note: I'm not a javascript expert (as you might have noticed from the fact I'm not very familiar with the way closures work in javascript), and I'm not really interested in IE compatibility. At this point pretty much everything I do consistently breaks in IE, which is probably not a surprise because I'm using popular HTML5 elements anyway. To conclude this message, I now think I pretty much understand how closures work in ecmascript. I still find it pretty unintuitive though, given the c-like syntax... Reminds me too much of c when it's in fact quite a different language. > It does not change the object. It does change the contents of the object. It does change the object... p and o aren't objects, they're references. By modifying o.j you're changing the object that o references. Changing the object and changing the contents of the object is essentially saying the same thing. What you're not changing are the values of o and p, which means they still reference the same object. But the object itself has been modified. I'm thinking you two are just saying the same thing, but clearly disagree on the vocabulary...
From: Stefan Weiss on 20 May 2010 23:21
On 21/05/10 03:15, Eleandor wrote: > Wow, I had no idea this would receive so many replies... Even though > most of them are irrelevant to my question. > > First some apologies: No need to apologize for anything. If it weren't for input like your question, we wouldn't have all those delicious semi-off-topic discussions :) > To conclude this message, I now think I pretty much understand how > closures work in ecmascript. I still find it pretty unintuitive > though, given the c-like syntax... Reminds me too much of c when it's > in fact quite a different language. That's a common problem. Similar syntax, but very different semantics. >> It does not change the object. It does change the contents of the object. > It does change the object... p and o aren't objects, they're > references. By modifying o.j you're changing the object that o > references. > Changing the object and changing the contents of the object is > essentially saying the same thing. What you're not changing are the > values of o and p, which means they still reference the same object. > But the object itself has been modified. Exactly. > I'm thinking you two are just saying the same thing, but clearly > disagree on the vocabulary... Definitely. Welcome to c.l.javascript :) -- stefan |