> ok, i see. But why does it work with variables that are set as global,
> e.g. the $HTTP_*_VARS:
>
> <?php
> function test() {
> global $HTTP_GET_VARS;
> $a = 'HTTP_GET_VARS';
> var_dump($$a);
> }
> test();
> ?>
>
global $foo;
is the equivalent of:
$foo = &$GLOBALS['foo'];
So when you access $$a, you're getting 'HTTP_GET_VARS' from the LOCAL symbol
table (where it exists as a reference of the global symtable version).
> this works inside a function. is it because of the global keyword? If so,
> why can't there be a "magic" "global $_GET, $_POST, $_SESSION ..." set in
> every function, for every superglobal, instead of the way it is handled
> now? The thing i don't get is, why the superglobals behave differently
> than "normal" global variables at all.
In a word: efficiency.
There's an expression: "Fast, Clean, Cheap: Pick Two".
The current implementation is Fast and Cheap, but as this thread has
highlighted, it's not entirely clean.
> Ok, you have explained the technical reasons, but that's not what i mean.
> For me as a php user (developing in php), the only difference should be,
> that i don't have to use the global keyword. Everything else seems like a
> bug or design flaw to me.
>
You won't hear a lot of argument from me. I just care less that it is the
way it is.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
