101–110 of 165 posts
Any program that uses a database has a very similar problem to global variables. As Gilad Bracha has pointed out, types are antimodular, and your database schema can be considered one giant type that pervades your program, just like globals can be. I don't think we have tools to compositionally solve this, across different programming languages.
Your program is also one giant type.
> If you run the code you'll see 1 2 3 4 3 printed instead of 5. I'm really confused, as this behaviour appears to be completely obvious to me.
Of course in a real life program, it may be lost in other code logic and, most importantly, the function performing the clone may not be so explicit about it (e.g. an "update" function that returns a different copy of the object).
It should have been "Mutability is the Problem, Globalness is not".
Earlier quoted context omitted.
The counter should be declared as static inside the function, thus limiting is scope and avoiding pollution of the global namespace.
In this case, yes. Its scope should be the lowest necessary scope. Does JS provide static variables in functions? If not, then that forces you to lift it to some other scope like file or module scope or the surrounding function or class if that's viable.
const f = (() => {
let cnt = 0;
return () => console.log("cnt", cnt);
})();
Earlier quoted context omitted.
That's only needed if you use multiple threads. In a single thread global vars are just fine, and much simplier than passing around ctx
And do you always know beyond any reasonable doubt that your code will be single-threaded for all time? Because the moment this changes, you're in for a world of pain.
The bug in the program reveals a poor understanding of object lifecycles by whoever wrote it. The `obj` argument to `simple` is not globally unique and so it makes a poor location to store global state information (a count of how often `simple` is called, in this example). Never tie global state information to ephemeral objects whose lifetime may be smaller than what you want to track. In this case, they want to know…
I like the diagnosis. My JS is terrible, but it seems like once you make the counter a global variable it is just better to change it to have an atomic dedicated count function. So instead of incrementing the counter in simple, a globalCount() function gets called that isolates the state. Something like { let i = 0; var counter = function (){ console.log(++i); } } Then call counter() to count & log and document that…
If you just look at what people normally mean by global variable, then I don't think the article changes minds on that.
Earlier quoted context omitted.
I like the diagnosis. My JS is terrible, but it seems like once you make the counter a global variable it is just better to change it to have an atomic dedicated count function. So instead of incrementing the counter in simple, a globalCount() function gets called that isolates the state. Something like { let i = 0; var counter = function (){ console.log(++i); } } Then call counter() to count & log and document that…
How is a globally-scoped closure not a global variable?