Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:14616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20050203235225.46734.qmail@lists.php.net>
To: internals@lists.php.net
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>
Date: Thu, 3 Feb 2005 15:52:23 -0800
Lines: 35
Subject: Re: referencing Superglobals with variable variables inside functions
From: pollita@php.net ("Sara Golemon")

> 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