It seems to be happening only under certain contexts.  Here is a script that works fine:

<?php

$test = 'asdf';

define ('_TEST', 'test');

echo 'constant: ';
print_r (${_TEST});

echo '<br />direct: ';
print_r ($test);

?>

And here is code that does not:

<?php

if (PHP_VERSION < '4.1.0') {
	define ('_GET', 'HTTP_GET_VARS');
} else {
	define ('_GET', '_GET');
}

class CGI {
	var $param = array ();

	function CGI () {
		global $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_POST_FILES;

		if (${_GET}) {
			reset (${_GET});
			while (list ($k, $v) = each (${_GET})) {
				if (get_magic_quotes_gpc () == 1) {
					$this->{$k} = stripslashes ($v);
				} else {
					$this->{$k} = $v;
				}
				array_push ($this->param, $k);
			}
		} else {
			echo '<br />_GET value: '; print_r (_GET);
			echo '<br />$_GET value: '; print_r ($_GET);
			echo '<br />${_GET} value: '; print_r (${_GET});
		}
	}
}

$cgi = new CGI;

echo '<br />$cgi value: '; print_r ($cgi);

?>

reclassified

You can't use superglobals indirectly, check this:

$t = "_GET";
var_dump ($$t);

doesn't work neither, and it wasn't supposed to work.

However, this does work (because $HTTP_GET_VARS is not a superglobal):

$t = "HTTP_GET_VARS";
var_dump ($$t);


Derick

But then why does it work under certain circumstances and not others?  Regardless whether intended or not, this is inconsistent behaviour.

I also think that having these differences between regular variables and the "superglobals" shouldn't be necessary.  If I can't use them in the same contexts as regular variables, then I would personally prefer the $HTTP_*_VARS instead, because you can.

I have found my approach to abstracting this difference ($HTTP_*_VARS vs. $_*) between PHP versions to be really beneficial to my scripts.  I can abstract them both down to one name, and use a single reference to the appropriate one instead of sticking if statements every time I need to know which one to use.

Sorry to keep buggin' ya, but I think this may be a fair enough argument for change.

True true. Derick (or someone else) mind briefly explaining why this is/has to be different?

Reclassified.

It should be documented that due the special way super globals are treated the cannot be used with variable variables.

I have already reported this problem, but nothing happened.
Superglobals seemed to be accessible with variable variables in the global scope, but not in any local scope (inside a function). Derick told me, that it is by design, but IMHO this is incosistent, and quite ugly :((

--
Goba

By design ? hehe

Ok, I *think* it was not 'by design', I think this just turned out to be the way it is after it has been implemented.  I don't think while writing the code and was kept in mind 'no, we do not want them not to be accessible in functions with variable variables'.

Ok, so much. Versions of PHP has already been released, so we should document it.

Btw, goba, using the search on php.net I couldn't find a single page refering to the super globals ... ? (I haven't yet browser through the manual index as I tend to find that annyoing)

Superglobals are named autoglobals or "auto global"s in many cases. Because you need not use "global" to make it global... I personaly think that superglobal is a better name for them (as used by Rasmus first AFAIK), so I use this name.

--
Goba

The feature of inability to use autoglobals / superglobals as variable variables is now documented in two places.  The variable variables page and the superglobals page.