3 ms·
In the basic case when you don't need to clone the world, you avoid the passing down on the call stack of what is truly a global variable, disguised as a local
by bluetomcat 8y ago
In the basic case when you don't need to clone the world, you avoid the passing down on the call stack of what is truly a global variable, disguised as a local instance. As a casual reader of such code, you might be deluded that `the_world` in `func1` is something different from `the_world` in `func2`, when they are the same.
If you plan to "virtualise" stuff later, instantiation is certainly the way.
- mpartel 8y agoI'd rather readers of such code take the (IMO minor) extra effort to consider the possibility of the worlds being different rather than bake the assumption that they're the same into even more code. That's how globals spread around your codebase, little by little, until it's very hard to refactor away from them. Better to just say no from the start. Also, if you have so many globals that passing them around as parameters / instance variables becomes truly tedious, that can be a valuable signal that the program is poorly structured. Of course, none of this matters in small codebases, as long as they stay small.