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.
>
> This has the double-edged effect of making it a standard to always use
> $_SERVER['argv'] for cli, and to discourage people from removing S from
> variables_order and using $_SERVER as their own variable name for something
> else.
>
> Making globals $argv and $argc always created is just cluttering the
> namespace even more, and (I think) breaks the idea of always putting
> variables into the superglobal $_* arrays.
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.
I think that making $_SERVER dependant on the settings of variables_order was wrong to begin with (I may have caused it to be that way in the first place, I don't remember, but all the same, it appears wrong). All the tricks with variables_order/gpc_order were there to allow people to work around problems with register_globals. Linking them with the auto globals doesn't make any sense to me, and is the source of the wtf factor here to begin with.
The only reason one may want not to populate the auto-globals is performance. I think that the cases where you would really like to disable one of those are rare. I think that our best bet is to always populate the auto globals, regardless of variables_order, and possibly provide means to explicitly turn them off for performance reasons.
Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
