<?php
function test() {
global $HTTP_GET_VARS;
$a = 'HTTP_GET_VARS';
var_dump($$a);
}
test();
?>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. 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. Sure i can work around the restriction somehow, but this should not be the final solution.
Sorry to bother you further. ;)
Michael
Sara Golemon wrote:
i must admit, that i don't know very much about the zend engine and the php core in general, but if "opline->op2.u.EA.type" "knows" if the variable is a local one, a global one or a static one, why hasn't it the value of ZEND_FETCH_GLOBAL for superglobals in the first place?
opline->op2.u.EA.type is set at compile time.
In the case of $_GET, the compiler knows that _GET is a superglobal so it sets it to ZEND_FETCH_GLOBAL
In the case of $$g (where $g was previously set to '_GET') the compiler doesn't know what $g is yet (since it's only really set at runtime), so it has no reason to set it to ZEND_FETCH_GLOBAL.
Could it be intelligent enough to see that in:
$g = '_GET';
$$g is always going to be '_GET' and therefor $$g and $_GET are really the same thing?
Perhaps.
But what about: $g = '_'; $g .= 'G'; $g .= 'E'; $g .= 'T';
Or the enigmatic: $g = '_TRG'; $g = str_rot13($g);
Building the run-time intelligence into a compiler would be.... well do I really need to spell that one out?
-Sara
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
