5 ms·

Very interesting. I'm not very familiar with Javascript but : The design used to solve test problems here is to pass the useful variables in the parameters of

• astral303 13y ago
  Being concerned about that is premature optimization (which is the root of all evil). It does not matter in any significant way vast majority of the time. If you have a really hot loop, OK, you can try removing value copies to see if that has an effect. But unless you've identified the hot code, do not prematurely optimize by avoiding parameters. Also all the expensive values are objects, and only references to them are copied, not the objects themselves.
• breck 13y ago
  This is what I used to think. I used to make my code pass lots of objects around in order to make it "faster", but in reality it was premature optimization, as the milliseconds lost passing a string by value is negligible compared to the dozens of developer hours lost by having less testable code.
• sirmarksalot 13y ago
  In the examples, the parameters are value types. However, in the real world, they are usually either objects or functions. Also, when you write code this way, you don't end up calling the constructors very often. You end up with a big up-front construction/wiring-up phase, after which your objects/functions go about their business handling user input and making server requests. I've found that this, combined with an MVC or MVVM methodology, essentially breaks my code down into functions and data records, with the two rarely intertwining. You basically only use the "new" operator either at the start of the program's lifetime, or when you're converting data from one data type to another.
• reissbaker 13y ago
  Not really, at least as compared to ordinary pass-by-reference. Javascript, like Java, uses references for all objects, but passes by value. So the references are passed by value, but the objects themselves are passed by reference (since they're always references). Passing references is quick, even by value: it's just passing around pointers. Here's basically how it would look in say, Go, with pointers: package main func main() { var x = 10 test(&x) println(x) } func test(ptr *int) { var y = 30 ptr = &y } And the equivalent JS: function main() { var x = 10; test(x); console.log(x); } function test(ptr) { var y = 30; ptr = y; } // depending on environment, either call main() or run on onload or DOM ready The main difference between the two is that in JS, x and y were already pointers; in Go, x is the actual value 10, and y is the actual value 30. However in both cases the test function takes a pointer that is itself passed by value. The programs, naturally, both print 10 and not 30. The pointer was passed by value, and modifying the value of the pointer only changes the pointer, not the referenced variable. To change the referenced variable you'd have to dereference the pointer — and since JS doesn't provide access to raw pointers, that's impossible in JS. You can, however, mutate the variable using array accessors or dot notation; for example, in Go: package main type Vertex struct { X, Y int } func main() { var z = Vertex{X: 1, Y: 2} println(z.X) test(&z) println(z.X) } func test(ptr *Vertex) { ptr.X = 10 } And once again the equivalent JS: function main() { var z = { X: 1, Y: 2 }; console.log(z.X); test(z); console.log(z.X); } function test(ptr) { ptr.X = 10; } // depending on environment, either call main() or run on onload or DOM ready As expected, the programs will first print 1, and then print 10. As you can see, pass-by-value in JS is generally the same as pass-by-reference in other languages; it's all pointers under the hood.
• vmarsy 13y ago
  I see thanks for the replies. So it's OK as long as you use objects and not a simple integer as a counter for instance.
  • astral303 13y ago
    Even then, use that simple integer as a counter and optimize only if it's slow. Speed of development and testability are much more important than optimizing parts of your code that rarely run.