function foo () {
global $var;
// rest of code
}
In my small PHP projects I usually go the procedural way. I generally have a variable that contains the system configuration, and when I nead to access this variable in a function, I do global $var;.
Is this bad practice?
Well, why don't you just test ? ;-)
Note: It is not as easy as you'd think -- read the full answer ;-)
Calling the hello_testing(); function, without setting the variable:
hello_testing();
I get no output -- which indicates isset returned false.
Calling the function, after setting the variable:
$conditional_random = 'blah';
hello_testing();
I get an output:
foo is inside
Which indicates global works as expected, when the variable is set -- well, one should not have any doubt about that ^^
But note that isset will return false if a variable is set, and null!
See the manual page of isset()
Which means that a better test would be:
function hello_testing() {
global $conditional_random;
var_dump($conditional_random);
}
hello_testing();
And this displays:
null
No Notice: the variable exists! Even if null.
As I didn't set the variable outside of the function, it shows that global sets the variable -- but it doesn't put a value into it; which means it's null if not already set outside the function.
While:
function hello_testing() {
//global $conditional_random;
var_dump($conditional_random);
}
hello_testing();
Gives:
Notice: Undefined variable: conditional_random
It proves that notices are enabled ;-)
And, if global didn't "set" the variable, the previous example would have given the same notice.
And, finally:
function hello_testing() {
global $conditional_random;
var_dump($conditional_random);
}
$conditional_random = 'glop';
hello_testing();
Gives:
string 'glop' (length=4)
(This is to purely to demonstrate my example is not tricked ^^)
Ideally, everything your function needs should be in a parameter.
function Sum($a, $b) {
return $a + $b;
}
If you really can't avoid referring to variables outside your function scope, you have several options:
Use the $GLOBALS array:
function Sum() {
return $GLOBALS['a'] + $GLOBALS['b'];
}
Use the global keyword:
function Sum()
global $a, $b;
return $a + $b;
}
Use an "anonymous" function and inject the globals
$Sum = function() use ($a, $b) {
return $a + $b;
}
$result = $Sum();
Anonymous functions are more useful if you want to work with variables in-scope of the functional declaration that aren't global.
extract() them from $GLOBALS
function Sum() {
extract($GLOBALS);
return $a + $b;
}
This last option will pull in all globals, and seems to be what you're looking for.
But seriously, parametize whenever possible.
They clutter up the global namespace and are slower to look up than local variables.
First of all, having many global variables is always a bad thing because it's easy to forget you declared a variable somewhere and accidentally re-declare it somewhere else. If your first variable was local then you don't have a problem. If it was global, then it just got overwritten. This gets even worse when you get into implied globals (e.g. when you say someVar = someValue without declaring someVar with the var keyword).
Secondly, global variables take longer for Javascript to "find" than local variables. The difference in speed isn't huge, but it does exist.
For further reading and a more in-depth explanation of why globals are considered bad practice, you may want to check out this page.
Here is what the book says on page 205:
If you’re familiar with operating system architecture, you might be interested to know that local variables and function arguments are stored on the stack, while global and static variables are stored on the heap.
This is definitely an error in the book. First, one should discuss storage in terms of storage duration, the way C++ standard does: "stack" refers to automatic storage duration, while "heap" refers to dynamic storage duration. Both "stack" and "heap" are allocation strategies, commonly used to implement objects with their respective storage durations.
Global variables have static storage duration. They are stored in an area that is separate from both "heap" and "stack". Global constant objects are usually stored in "code" segment, while non-constant global objects are stored in the "data" segment.
When people talk about global variables in other languages it means something different to what it does in PHP. That's because variables aren't really global in PHP. The scope of a typical PHP program is one HTTP request. Session variables actually have a wider scope than PHP "global" variables because they typically encompass many HTTP requests.
Often (always?) you can call member functions in methods like
preg_replace_callback()like this:See callbacks for more.
The point is that objects have been bolted onto PHP and in some ways lead to some awkwardness.
Don't concern yourself overly with applying standards or constructs from different languages to PHP. Another common pitfall is trying to turn PHP into a pure OOP language by sticking object models on top of everything.
Like anything else, use "global" variables, procedural code, a particular framework and OOP because it makes sense, solves a problem, reduces the amount of code you need to write or makes it more maintainable and easier to understand, not because you think you should.