Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14619
Return-Path: <michael.virnstein@brodos.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 93405 invoked by uid 1010); 4 Feb 2005 00:19:57 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 93390 invoked by uid 1007); 4 Feb 2005 00:19:57 -0000
Message-ID: <20050204001957.93389.qmail@lists.php.net>
To: internals@lists.php.net
Date: Fri, 04 Feb 2005 01:19:56 +0100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20050128223155.81436.qmail@lists.php.net> <5.1.0.14.2.20050128145327.04025190@localhost> <20050128233054.9657.qmail@lists.php.net> <20050128234649.27693.qmail@lists.php.net> <20050128235345.42569.qmail@lists.php.net> <20050130193103.63809.qmail@lists.php.net> <20050131182732.84357.qmail@lists.php.net> <20050131211614.84286.qmail@lists.php.net> <20050131222442.61678.qmail@lists.php.net> <20050203221208.67112.qmail@lists.php.net> <20050203235225.46734.qmail@lists.php.net>
In-Reply-To: <20050203235225.46734.qmail@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 62.226.9.103
Subject: Re: referencing Superglobals with variable variables inside functions
From: michael.virnstein@brodos.de (Michael Virnstein)

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