However, if you're a programmer with a 10,000 line application, are you going to just forget that you've used your $cfg variable a hundred times, and accidentally make a new one? And the error is detectable.
Maybe all superglobals could be required to start with an underscore, like _GET and _POST, to decrease confusion. I personally don't think this would be necessary, but it is a compromise. But what you're saying applies to the php superglobals too, what if someone makes a variable called _GET? It will have the same problem. And you can say, yeah but _GET is an obscure name, to that I would say we can require superglobals to start with underscores or something. But regardless, if someone specifies a superglobal it's on them to remember, it's not our job to protect a sloppy programmer who does stupid things in his coding. This feature would maybe be a disadvantage to a couple people who abuse the flexibility we give them, but it would benefit many more people. Flexibility does not hurt anyone except the people who abuse it. If they're going to make mistakes like this, they're going to make mistakes regardless. We don't have to hold back new features and flexibiltiy in order to prevent a couple of people from messing up. If everyone went by this logic then PHP would not even have functions, because people might use them wrongly. On Fri, 2007-11-16 at 18:00 -0800, Stanislav Malyshev wrote: > > Well this is very common with PHP, it's very flexible and it's easy for > > a bad programmer to create chaotic code and get away with it, but this > > can happen with many features of PHP. For serious developers however, > > Right. This is why I don't think it's a good idea to add one more > feature with very high potential for abuse. Code that changes behaviour > of unrelated other code is usually very bad idea - think about what > happens if some of your functions somewhere among 10K lines of code used > $cfg as local variable and then you added $cfg as superglobal. > > > them. No point in holding stuff back from people who could benefit from > > it just to protect inexperienced them from their own sloppiness. You > > know what I mean? > > Yes, there is a point in not implementing features that would promote > bad coding and unnecessary surprises for the users. Especially when the > same function can be achieved with existing functionality in a much > better way. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
