Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: 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 Previous Comments: [2002-04-19 21:01:49] [EMAIL PROTECTED] 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) [2002-04-19 15:17:41] [EMAIL PROTECTED] 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 [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: 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) Previous Comments: [2002-04-19 15:17:41] [EMAIL PROTECTED] 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 [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] 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. [2002-04-19 10:33:59] [EMAIL PROTECTED] 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 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Red Hat Linux 7.1 PHP Version: 4.2.0 New Comment: 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 Previous Comments: [2002-04-19 14:53:51] [EMAIL PROTECTED] Reclassified. It should be documented that due the special way super globals are treated the cannot be used with variable variables. [2002-04-19 12:40:50] [EMAIL PROTECTED] True true. Derick (or someone else) mind briefly explaining why this is/has to be different? [2002-04-19 11:11:00] [EMAIL PROTECTED] 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. [2002-04-19 10:33:59] [EMAIL PROTECTED] 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 [2002-04-18 19:09:09] [EMAIL PROTECTED] reclassified The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/16687 -- Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
-Bug Type: Scripting Engine problem
+Bug Type: Documentation problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
Reclassified.
It should be documented that due the special way super globals are
treated the cannot be used with variable variables.
Previous Comments:
[2002-04-19 12:40:50] [EMAIL PROTECTED]
True true. Derick (or someone else) mind briefly explaining why this
is/has to be different?
[2002-04-19 11:11:00] [EMAIL PROTECTED]
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.
[2002-04-19 10:33:59] [EMAIL PROTECTED]
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
[2002-04-18 19:09:09] [EMAIL PROTECTED]
reclassified
[2002-04-18 17:30:28] [EMAIL PROTECTED]
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16687
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
True true. Derick (or someone else) mind briefly explaining why this
is/has to be different?
Previous Comments:
[2002-04-19 11:11:00] [EMAIL PROTECTED]
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.
[2002-04-19 10:33:59] [EMAIL PROTECTED]
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
[2002-04-18 19:09:09] [EMAIL PROTECTED]
reclassified
[2002-04-18 17:30:28] [EMAIL PROTECTED]
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
[2002-04-18 16:43:17] [EMAIL PROTECTED]
Constants do not appear to be interpreted properly in the following
context:
${CONSTANT}
I found this problem with the following code:
This should print out the $_GET hash in 4.2.0RC4, but it prints
nothing. A quick check of the _GET constant shows that it does contain
the proper value.
I compile php with:
'./configure' '--with-pgsql=shared' '--with-gd'
'--with-mysql=/usr/local/mysql'
'--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
'--enable-xslt' '--with-xslt-sablot'
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
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.
Previous Comments:
[2002-04-19 10:33:59] [EMAIL PROTECTED]
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
[2002-04-18 19:09:09] [EMAIL PROTECTED]
reclassified
[2002-04-18 17:30:28] [EMAIL PROTECTED]
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
[2002-04-18 16:43:17] [EMAIL PROTECTED]
Constants do not appear to be interpreted properly in the following
context:
${CONSTANT}
I found this problem with the following code:
This should print out the $_GET hash in 4.2.0RC4, but it prints
nothing. A quick check of the _GET constant shows that it does contain
the proper value.
I compile php with:
'./configure' '--with-pgsql=shared' '--with-gd'
'--with-mysql=/usr/local/mysql'
'--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
'--enable-xslt' '--with-xslt-sablot'
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
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
Previous Comments:
[2002-04-18 19:09:09] [EMAIL PROTECTED]
reclassified
[2002-04-18 17:30:28] [EMAIL PROTECTED]
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
[2002-04-18 16:43:17] [EMAIL PROTECTED]
Constants do not appear to be interpreted properly in the following
context:
${CONSTANT}
I found this problem with the following code:
This should print out the $_GET hash in 4.2.0RC4, but it prints
nothing. A quick check of the _GET constant shows that it does contain
the proper value.
I compile php with:
'./configure' '--with-pgsql=shared' '--with-gd'
'--with-mysql=/usr/local/mysql'
'--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
'--enable-xslt' '--with-xslt-sablot'
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Variables related
+Bug Type: Scripting Engine problem
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
reclassified
Previous Comments:
[2002-04-18 17:30:28] [EMAIL PROTECTED]
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
[2002-04-18 16:43:17] [EMAIL PROTECTED]
Constants do not appear to be interpreted properly in the following
context:
${CONSTANT}
I found this problem with the following code:
This should print out the $_GET hash in 4.2.0RC4, but it prints
nothing. A quick check of the _GET constant shows that it does contain
the proper value.
I compile php with:
'./configure' '--with-pgsql=shared' '--with-gd'
'--with-mysql=/usr/local/mysql'
'--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
'--enable-xslt' '--with-xslt-sablot'
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
Bug #16687 Updated: Constants not being interpreted in "variable variables"
ID: 16687
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: Red Hat Linux 7.1
PHP Version: 4.2.0
New Comment:
It seems to be happening only under certain contexts. Here is a script
that works fine:
direct: ';
print_r ($test);
?>
And here is code that does not:
{$k} = stripslashes ($v);
} else {
$this->{$k} = $v;
}
array_push ($this->param, $k);
}
} else {
echo '_GET value: '; print_r (_GET);
echo '$_GET value: '; print_r ($_GET);
echo '${_GET} value: '; print_r (${_GET});
}
}
}
$cgi = new CGI;
echo '$cgi value: '; print_r ($cgi);
?>
Previous Comments:
[2002-04-18 16:43:17] [EMAIL PROTECTED]
Constants do not appear to be interpreted properly in the following
context:
${CONSTANT}
I found this problem with the following code:
This should print out the $_GET hash in 4.2.0RC4, but it prints
nothing. A quick check of the _GET constant shows that it does contain
the proper value.
I compile php with:
'./configure' '--with-pgsql=shared' '--with-gd'
'--with-mysql=/usr/local/mysql'
'--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-shmop'
'--enable-xslt' '--with-xslt-sablot'
Thanks!
--
Edit this bug report at http://bugs.php.net/?id=16687&edit=1
