To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
