bla bla _G bad for good reason. In normal Lua _G and shared are different, but in Roblox _G and shared function the same. _G and shared are still separate tables, but they do the same thing. The arguments I’m making here don’t necessarily apply to regular Lua.
The biggest problem with using _G is that invariably, people use it to hold static values. Things that always exist. _G is great for things that pop in and out of existence (i.e. as a list of parts correlating to a certain dynamic system in your game) but using _G for anything that doesn’t change is a mistake.
Let me share some history, because using _G for this purpose is a habitual holdover from before ModuleScripts. Until ModuleScripts (and BindableEvents) existed, scripts could not access the contents of other scripts. The only two ways to communicate between scripts was to change Value objects (i.e. StringValues etc) or use _G/shared That was never an issue in vanilla Lua. So Roblox developers used _G to communicate variables between scripts. This doesn’t work in vanilla Lua, but for Roblox developers it was essential.
The things that developers used _G for were always bad practice. Bad in a way that you’d get fired if you tried a similar system at a real company. But since ModuleScripts started existing and we have an alternative, we no longer need to resort to that bad practice.
Feel free to use _G if you need to hold a list of dynamic objects, but remember that even then, the vanilla Lua couterpart shared is seldom used in the real world. Dynamically populated mystery lists. Doesn’t sound so good when I word it like that, does it? You can’t tell from another file when the data will be populated, what the data will be, intellisense and typechecking is disabled, and when you write another file you need to consider the implications of storing something in a global table that may or may not be expecting a certain structure that you’re breaking. It’s difficult to read and impractical to maintain.
But no, other than what I’ve listed, there’s nothing wrong with it.
It’s the real world. Roblox developers are pampered with easy coding, they forget how lengthy things can be in the real world. But even if you want to go this route, you can make a directories ModuleScript instead of a directories _G. They’re functionally the same except one is easy to edit and maintain. I mean, you already need a script to set up the _G table, right? Just make it a ModuleScript and it’s already that much easier to edit in the future. And your scripts don’t need to wait for the data to exist. And you get typechecking and intellisense. It’s just so much better.
