views:

79

answers:

5

So I got a lot of responses from this site that global variables are bad and kill puppies.

What if I use such variables like this:

function get_stuff(){
  global $stuff;
  if(!stuff) $stuff = 'candy';
  return $stuff;
}

function screen_output(){
  $stuff = get_stuff;
  echo $stuff;
}

does this make the code better than using 'global' in both functions?

ps: If you want to know the reason why I need to use a global variable, it's because I need to retrieve some settings from the database, and I don't want to call the db from every function.

A: 

No, it doesn't. You should totally avoid globals and rather pass stuff as arguments.

Hanse
A: 

Why not store the settings on encrypted cookies? I know this could possibly lead to session hijacking but if you're only using it for web settings I would give it a try.

kirbuchi
+1  A: 

That's worse. You're trading one global symbol ($stuff) for another (get_stuff), with the aggravating factor that the way you did it you're using both.

By the way, I think you wanted to say

if ($stuff === null) $stuff = 'candy';

or at least

if (!$stuff) $stuff = 'candy'; //also reset when stuff is '', 0, etc.
Artefacto
A: 

You don't need a global variable to accomplish that code. You could create a Singleton object that gives your script access to only one instance of the database connection. The global variable is bad because it's accessible by your entire application, even the parts that don't need it.

Evan Kroske
Nope. `Database::createInstance()` has the same problems as `global` and Singletons are generally a bad idea.
Gordon
so there's no alternative to global then?
Alex
@Alex Of course there is: use [Dependency Injection](http://fabien.potencier.org/article/11/what-is-dependency-injection): *"Dependency Injection is where components are given their dependencies through their constructors, methods, or directly into fields."*
Gordon
that looks like is using sessions. someone mentioned that using sessions is just as bad as globals
Alex
@Alex nope, dependency injection is something entirely different. See also: http://stackoverflow.com/questions/1812472/in-a-php-project-how-do-you-organize-and-access-your-helper-objects
Pekka
@Alex I think you misunderstood @Pekka when he said [*using Sessions is as bad as using globals*](http://stackoverflow.com/questions/3159553/php-temporary-variable/3159637#3159637). He did not mean to say *Sessions are bad in general*. He meant they are the wrong tool *for that particular problem*.
Gordon
+1  A: 

Ideally, you would have a class that handles the data and is instantiated when the data is retrieved and/or used for each record or set of records from the DB. The object created in this way, would then be passed from function to function as needed. This thinking normally leads people to eventually using Object Relational Mapping software, which is specifically designed to handle moving data in and out of a database or other persistent(ish) storage. That said, understanding the purpose of ORMs requires some knowledge of Object Oriented Programming and the commonly used patterns of the paradigm, so researching OOP might be a better place to start looking for answers. A wikipedia search on these topics would be a good idea.

As a general rule, consider that computer systems are better(more testable, fixable, extensible, replaceable) when the individual parts are encapsulated(isolated) from one another. So by doing something in a global way(this goes well beyond just declaring something global) you are interconnecting parts of the system that probably don't need to be connected.

How this isolation is done and to what degree is determined by you and the type of system you are building. If you are just writing some simple test code or a simple prototype, you can abuse global space as much as you want since the code will never see the light of day(keyword here is simple). If you are building a simple script that helps generate a couple web pages and that script will never evolve into anything more then that, you still don't have to worry about the global space much. But once you move beyond the trivial, you really should start isolating the parts of the system, as it will give you much better code to work with down the road(meaning pretty much as soon as it is typed in and compiles)

The more complex a project becomes, the more isolated the parts should be, so that a change in one area doesn't 'ripple' through the entire system. This ripple could be looked at as having to change something in the code in a hundred places instead of just a few or in the resulting bugs that come up after the fact because not everything was changed over or changed correctly(Human error will always win out here).

tsgrasser