As a predecessor of mine at work devised not one but two systems that used global variables as their primary means of internal communication, and I got to sit next to the guy who had to debug and maintain both of them for a year before finally going insane and quitting, I have to agree with Rasmus. Typing "global" isn't just an extra six characters. It's being polite to the people who will have to maintain your code after you're gone. Undeclared globals are a form of extreme sadism, no matter how much documentation you think you've provided. Declared globals are merely ordinary, run-of-the-mill sadism. :-) I don't see a benefit in the first place.
Singletons, collector functions, or as a last resort the global keyword are all viable alternatives. Leave extra superglobals to runkit where such weird edge cases belong. On Friday 16 November 2007, Sam Barrow wrote: > I disagree, although you do have a very good point. But simple logic > flaws can cause huge bugs regardless, whether it would be because of a > superglobal or any other programmer error. Although you have a point, > the only place where we disagree is that I think the benefits outweigh > the risks. > > On Fri, 2007-11-16 at 20:34 -0800, Rasmus Lerdorf wrote: > > Sam Barrow wrote: > > > You say that superglobals were not designed to be user defined, think > > > about it, the concept of a superglobal is present in C and C++, two of > > > the maturest and strictest languages around. > > > > The concept of having to declare your globals is unique to PHP, true. > > It is one of the oldest features in PHP too. So, a little history... > > > > Back in 1989 I spent at least a month chasing a bug at a company in > > Canada called Bell Northern Research. It was a weird crash bug in a > > rather complicated system. It was mostly written in C and after pouring > > through reams and reams of code printouts day after day, I finally found > > that it was due to a side effect of some obscure function overwriting a > > global variable that was used in a completely different area of the > > code. That particular feature of the C language was not popular with me > > for a long time after that, and when it came time to work out function > > scoping of variables in PHP, I made sure to not make that same mistake. > > > > And yes, because PHP is a web language and there are common aspects of a > > web request that many functions will need to act on, it makes sense to > > have a finite number of clearly labeled global arrays like _GET, _POST, > > etc. And later on, being able to access any global via $_GLOBALS was > > added, but again, it is a very descriptive name and not likely to result > > in someone mistaking it for something else and ending up with strange > > side effects. > > > > I am definitely not in favor of destroying what I consider a rather good > > design decision just to avoid a couple of keystrokes here and there. So > > yes, you will have to keep adding "global $cfg;" to your functions, or > > accessing it via $_GLOBALS['cfg'], and when you forget, it won't work. > > And yes, you will grumble a bit at that, but that is nothing compared to > > trying to find a bug caused by a global side effect in someone else's > > code. Trust me, you will grumble a lot more at that. > > > > -Rasmus -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
