On Mon, 6 Oct 2003, Greg MacLellan wrote: > > > That was my argument. I was saying that instead of ALWAYS creating $argv > and > > > $argc, regardless of register_global status, it should ALWAYS create > > > $_SERVER['argv'] and $_SERVER['argc'], regardless of variables_order > > > setting. > > > > My big problem with this approach is that when variables_order does not > > include "S" then it seems inconsistent to have a partially populated > > $_SERVER array. If $_SERVER['argc'] is there, why aren't other normal > > $_SERVER variables available? The wtf factor is a little too high for my > > tastes. > > Hmm. I think that's my problem with the $argv/$argc method too. If > register_globals is off, why are globals getting created? If nothing else, > $_SERVER is one variable, $argv and $argc are two.
I think you have the wrong idea of what register_globals means. Turning off register_globals does not mean that your global symbol table will suddenly be empty. There are plenty of variables registered in the global symbol table. register_globals guides whether user-defined variables are allowed to be created in the global symbol table. Having $argc/$argv in the global symbol table has nothing to do with register_globals. These variables are not named by the user. It also provides a nice symmetry with other languages that make argc/argv available this way. > Maybe this situation (where register_globals = off, and variables_order > doesn't contain 'S') should just generate a warning (though I'm not sure > where, in this context. Are there any other warnings at startup?)? Why? This is a perfectly valid config. > Another option would be to introduce a new superglobal, $_ARGV, only for > cli. IMO, argc is a bit antiquated anyways, as you can always use count(), > or even just foreach to go through. What may be an issue with this is that > $_ARGV would be a numerically-indexed array of the options, whereas the rest > of the superglobals are indexed by strings and all have meanings. It's also > a bit of a big change, and would mean that code written for this version > wouldn't be backwards-compatible. I'm not sure what the opinions of most > people are about making these sorts of changes.. maybe this is something > that could be introduced in PHP5? I guess you could argue that this is slightly cleaner, but the fact that it isn't backwards compatible makes the hassle factor too high for such a marginal cleanliness gain. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
