4 ms·

I seriously don't understand why people hate any use of globals? I've written a 20k line MRP system that spans over 100 different PHP files. I have a global "$l

• _Lemon_ 16y ago
  You're specifically using it for configuration/preferences though. You should consider changing it to a constant instead as that's what they really are. The problem is passing state around in global variables. Any code can (and readily does) modify the state which is the problem.
  • chime 16y ago
    $db wouldn't work as a constant. You're right that look_ahead/company_address would work as a define("CONSTANT") better but honestly, I hate not putting a $ sign in front of a value (constant or variable). I am more prone to missing a $ than redefining a global. I don't remember ever having the problem of redefining a global unintentionally. I can give 20 examples of when I missed a $ symbol and PHP gave me an error/notice. If PHP constants had a symbol akin to $ (say #), I would definitely use them. But I just feel dirty typing "echo LOOK_AHEAD;" in one place and "echo $look_ahead_partial;" in another because I don't want to get in the habit of putting $ in some places and not putting them in others.
    • _Lemon_ 16y ago
      $db is something different altogether, in my code I have a cheap Database class and each model creates a new one -- but it relies on the MySQL functions it uses to re-use the database connection. So in reality it's the same thing. The problem with not using a constant where it's necessary is that you're communicating the wrong thing to someone else or even yourself 6 months down the line. You might want to re-evaluate what you see as "ugly code" especially if it changes how you write the code.
    • robryan 16y ago
      Not only that but depending what kind of db wrapper class you have you probably want it to be modified by the code that touches it. Sure you could pass it around, I guess it depends on how many people touch the code. Personally I global the database wrapper, the user session class and config stuff (which yes I could use constants). Although if the code base I'm referring to wasn't 95% me coding I would probably consider using global less.
    • nir 16y ago
      On the other hand, when someone reads "echo LOOK_AHEAD" they immediately know it's a constant and thus (a) global and (b)(more importantly) defined once and never modified by the code. With "echo $look_ahead" there's no indication of that, and in the future another dev might add something that modifies $look_ahead's value and break other parts of the code, making for sneaky bug (which incidentally is why non-constant globals are so disliked ;))
• DjDarkman 16y ago
  Store them in static private variables of a singleton object. An example http://pastebin.com/Gf4fzHn2 http://pastebin.com/Gf4fzHn2 This way you could lookup the parts of the code that use your global stuff, because they have to get it though the static method call.
  • chime 16y ago
    This is exactly what my argument was against. Why make it complex when a simple global would do? Why say GlobalSingleton::var when global $unique_var would do, as long as the app does not abuse these global vars?
    • DjDarkman 16y ago
      It's a few lines of code, I would not call that complex. And the usage is. GlobslSingleton::set('Something Meaningful',$unique_var); and GlobslSingleton::get('Something Meaningful'); I don't think this is complex at all. This doesn't force you to use $unique_var as a variable name(I know it can be worked around). One of the biggest problem with globals is that they can crash and burn if someone else's code purges it by accident. Also my pattern allows 'load on demand', I can incorporate it in if I'd want to, your does not.
      • lox 16y ago
        Might I suggest something like Config::get('look_ahead') rather than GlobalSingleton? The design pattern used to implement something is generally far less useful than the purpose of the thing in terms of a name.
        • DjDarkman 16y ago
          Of course.
• Chris_Newton 16y ago
  Food for thought: 1. As another responder mentioned, some of your examples sound more like named constants than global variables. 2. Not using global variables is just an example of a more general rule: variables should generally have as small a scope as possible. The wider the scope, the harder it is for someone reading the code to understand how the variable is used, and the riskier it becomes to change that code. 3. 20K lines and 100 files is a small project, in the sense that one person can be familiar with all of it. While limiting scopes is still beneficial for readability on that scale, it really starts to pay off when there are multiple people working on a project and no one person knows the whole thing. I see parallels with modular design generally here: although it is helpful even on quite small projects, you can get away without it up to a certain point. Beyond that point, you really start to suffer from having different parts of your system tied together in ad-hoc, uncontrolled ways.
• arghnoname 16y ago
  Globals can make sense. In C it isn't unusual at all to see a variable that is global in file scope only, which is similar in effect to how class variables are treated within the class definition in a variety of OOP languages. The problem is PHP's scoping rules don't lend themselves well to this kind of thing. If you were to use a PHP library, for instance, that used the same practices you are using, say a parser, you might find that depending on the include order $look_ahead now means something different. This kind of "all I did is include a file and everything broke" error is really annoying to find. Constants are useful for this, because at least it will flag an error/warning. Now that PHP has (is getting? It's been a while) namespaces, you can limit its scope and make it less likely to collide. For the case of databases, it is fairly common to use PHP's builtin functionality to reuse the database connection without having to rely on a global handle. Again, if someone shares your practices the variable could end up getting stepped on. Throw in autoloading and maybe it only occurs when some confluence of events leads to some specific file being included that usually isn't. So there's a reason for concerns about globals. Putting everything in a singleton with static variables is not really different, but in my mind mostly just namespaces it so your globals don't get in trouble with someone else's globals. I've found in practice that I've only rarely needed global variables or singleton classes housing global variables. This probably largely depends on your style of coding. I haven't written in PHP for years now so if I've gotten any details wrong please forgive me. Hopefully though you can see some ways that frequent use of globals can lead to hard to find bugs. A lot of programming techniques (OOP, closures, for example) are designed to help pass around state in ways that don't lead to these kinds of problems.
• lox 16y ago
  Don't you get sick of all the "global $look_ahead;" cruft at the top of your functions? Also, what happens when one of your new developers comes along and modifies the value of that in some unexpected way?