Re: referencing Superglobals with variable variables inside functions

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(); ?> 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