I've been getting more into using global lists for a variety of things for some time now, mainly icon storage for quick fetches, keeping track of objects and mobs and whatnot in the game.
However, I have been told quite early on that using these global lists is a bad thing, I mean, in basic, using var/global/LOLOBJECTS without putting them inside an atom could be bad because everything in your works will hold it's information, but other than that, what are the real ups and downs of using them?
ID:1572893
 May 13 2014, 2:23 am
|
|
Keeping a global list of foo's is, of course, much better than finding and creating a list of foo's on-demand, assuming you need said list with any degree of frequency. So certainly try to use a for(var/mob/M in mob_list) instead of for(var/mob/M in world) when you can, unless said access isn't done often enough to be a resource hog.
If your variable is already unscoped, you don't need to define it as global. It doesn't mean anything unless there's more than one instance of src, although I guess it could help with readability for other people. I would argue against defining singular, unscoped variables as global as that gives the wrong impression of what global means. | |
However, I have been told quite early on that using these global lists is a bad thing Odds are, a lot of that is completely bad advice. I'm a strong proponent of global values. The only thing you have to remember is that global values cannot be depended upon after a sleep/spawn. See my Edge Sliding demo. I actually use a single global collider object for all mobs that use the sliding behavior. Because multiple objects can use the object, I have to make sure that any state changes get restored in the same frame. Global variables/lists aren't a bad thing. They absolutely have their uses. | |
Your example is pretty much something that meets with the requirement of 'truly global, and truly singular in nature'. It's very rare indeed, for instance, that a variable that once meant "all the players in the world" needs to take on a different form.
So it's obviously pants-simple to just make that a global, no question. | |
Unless the data contained within the variables in question is truly global, and truly singular in nature, it should really be tucked into some kind of datum somewhere at least.
When global, it's very tempting (rightly or wrongly) to access the variable from anywhere. Once you've done that, you have a variable, who's definition is nowhere near the code actually using the variable in question.
What object type is this variable? What can I assign to this? What's it meant to be used for? All of those questions involve a jump, from where you are now in the code, to ... probably some other file entirely, for clarification, then jump back. The mouse-clicks for that aren't really a big deal. The mental context switching however, is. It breaks your mental flow, you need to go "Right, now I know that ..." and get back onto what you were doing before. If you combine that with vague naming (which globals tend to suffer, being ... you know, general, global) and a reasonably sized codebase and you slowly end up cursing excessive use of globals.
The other consequence of course is that should you end up needing to replace the variable entirely, perhaps with a datum, maybe change the type of the variable, replace with 2 or 3 or whatever, a whole bunch of code elsewhere now needs to change. In some cases, that's life, it happens. Usually though, a lot of that could be mitigated by better encapsulation, and not having exposed the variable globally in the first place.
Not using bare global variables makes those changes much easier, because global variables tend to encourage tight coupling. A case in point is Chatters support for saving server data to either savefile or MySQL. We'd pulled much of that logic into a datum first (a datum for managing saving a chatter, for saving the ban/mute lists etc), and that meant when I went to add MySQL saving support, I just extended that datum with a MySQL version, one file change, and the rest of the code could stay pretty much exactly as it was. As opposed to having to axe the global ban lists, replace them with a datum, update the 20 or so places that would have been interrogating the ban lists etc.