On Mon, 2007-12-24 at 12:13 -0500, tedd wrote:
> At 4:18 PM +0200 12/19/07, Sancar Saran wrote:
> > > that said, avoid globals like the plague - sometimes you may come up with
> >> a situation where using a global is really necessary - such situations
> >> should be the exception rather than the rule, often if your thinking of
> >> using a global there is another way of doing it. jmho
> >
> >And this is why I'm asking here, WHY I should avoid globals like plague ?
> >Every one says bad. Alright, but no one says WHY ?
>
> Hi:
>
> I'm a little late to this thread (been busy), but this is why I
> rarely use globals and have not used them in php.
>
> One of the fundamentals of programming I've learned is to reduce
> problem/solution to their most basic form. Simply, you see a problem
> and you solve it by dividing the problem it into smaller parts and
> then writing code to solve the small parts. Eventually, all the small
> solutions come together to solve the larger problem.
>
> Certainly, and it seems even logical, that you can use a global
> variable to communicate between the different parts and everything
> should work -- IF -- that's all there was to it. But, if you have to
> debug the code OR if you want to use a portion of that solution to
> solve a different problem, then you can have difficulties. For
> example:
>
> [1] If you have to debug the code, there's not a really good way to
> look at a function and see if a variable in it is a global or not --
> therein lies a problem, you don't readily know.
>
> In other languages I adopted a naming convention that used "g" as the
> first letter of a Global variable, like gThisIsMyGolbalVariable --
> that way at least I knew the variable was global. But, even then I
> didn't know where the global was defined or where it might be changed
> -- it was just an unknown in my function that I had to consider.
>
> [2] If you want to reused a portion of the code, then you have to
> also accommodate the global. This makes transporting your code from
> one application to another problematic because you never know IF your
> function replies on a global or not. If you never use globals, then
> that's never a problem.
>
> So, my advice is to not use globals, but rather make the functions
> independent from globals. That way you troubleshoot them easier and
> can cut/paste them into other solutions without having to worry if
> some part of that function relies on something who knows where.
>
> That's my reasons why I avoid globals.
You're advice isn't very applicable in some cases. I absoltely agree it
is very bad coding style to use globals to communicate information from
one function to another etc. For instance, using globals to facilitate a
database connection is very bad IMHO, the DB connection should be
retrieved from a function or singleton... I've seen this be a very real
problem when I've been asked to merge code from separate projects into a
unified system. Additionally, I generally agree that using the global
keyword and then stealthily using a global variable reduces clarity of
where the variable came from. However, this is mitigated by using the
$GLOBALS struct explicitly. Also, by using the $GLOBALS struct
explicitly there's no need to prefix your variable names with 'g' :)
Although, in JavaScript and in C on the occasion where I've used
globals, I also use a 'g' prefix for clarity. Continuing on though, as I
said in a previous message, using the $GLOBALS array for project
configuration is very convenient and IMHO clean provided that you use a
double level methodology where the first level is the name of your
project or some other unlikely to be clobbered name. For instance,
InterJinn has most of it's framework settings declared via:
$GLOBALS['interJinn']['someConfigProperty'] = 'someValue';
I find this clean, readable, maintainable, and without the need for a
superfluous solution to handle framework configuration. One could use
the fairly standard .ini convention with key/value pairs, but this is a
pain for arrays, generally requires a caching system once parsed, and
can't even nearly compete with compile cached PHP code :)
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
