Closure bug
in [JavaScript]
|
Prev: Microsoft Visual Web Developerr
Next: FAQ Topic - What is the Document Object Model (DOM)? (2010-05-17)
From: Lasse Reichstein Nielsen on 20 May 2010 12:09 Richard Cornford <Richard(a)litotes.demon.co.uk> writes: > 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? I sure hope you can't since that's probably how all implementations handle strings (and some handle large numbers that way too). :) /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Ry Nohryb on 20 May 2010 12:16 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 ? -- Jorge.
From: Richard Cornford on 20 May 2010 12:23 On May 20, 5:09 pm, Lasse Reichstein Nielsen wrote: > Richard Cornford writes: >> 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? > > I sure hope you can't since that's probably how all > implementations handle strings (and some handle large > numbers that way too). :) Yes, an implementation in a language that has no string primitives (such as Java) would have little choice but employ some sort of object to represent javascript's string primitives. On the other hand, javascript implemented in javascript (i.e. Narcissus) might use javascript's string primitives to represent javascript string primitives (probably best not to start thinking about the implications of that, but at least in that implementation we can be sure that 'pointers' to memory addresses are not being used, as there are none to use). Richard.
From: Johannes Baagoe on 20 May 2010 12:34 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. -- Johannes
From: Richard Cornford on 20 May 2010 12:34
On May 20, 5:16 pm, Ry Nohryb wrote: > On May 20, 6:09 pm, Lasse Reichstein Nielsen 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 ? Javascript uses 64 bit floating point numbers, so they must occupy at least 8 bytes (and probably more in reality as javascript values need to know, for example, what type they are in case they get asked). However, it has been pointed out that there are cases where the complier can observe variables, being assigned number values, and being employed in such a way as to, say, guarantee that a 32 bit signed integer could do the job (i.e. a loop counter starting at zero and counting up to some known value). This opens the door to optimisations where (alternative,) smaller number types could be used to save memory and processing time. This is a case where you can cheat if you can know you will get away with it. So a smaller number (sometimes) could occupy less space than a large one. Richard. |