I spoke briefly with Jan about the following (imho) mis-feature,
who recommended bringing it up on the dev-list.

  http://bugs.php.net/?id=14952

I ran into the problem (as an end-user) while trying to muck 
with what the user had passed in (ie: spoof GET data from
session-ized defaults if the user did not select anything).

Why isn't it: $_GET =& $HTTP_GET_VARS?

Attached is my understanding of the problem.  As it stands
right now, I do not want to use $_GET constructs in my code
because $_GET is not a drop-in replacement for:

  $GLOBALS['HTTP_GET_VARS'][...]

...which I assumed it was. No matter where I set a value for
$GLOBALS['HTTP_GET_VARS'], it will be the same throughout
script execution.  With the addition of the $_GET class of
variables, there are suddenly two copies of data, two areas
to manage in your code.  IMHO, it is a bad move for the data
to be separated in the long run, especially when there is not
a good reason for it.

If the world were a perfect place (which it isn't, and I know
it ;^) ... I would say that:

  $_GET =& $GLOBALS['HTTP_GET_VARS'];
  $_POST =& $GLOBALS['HTTP_POST_VARS'];
  $_COOKIE =& $GLOBALS['HTTP_COOKIE_VARS'];
  $_REQUEST =& array_merge( $_GET, $_POST, $_COOKIE );

I know that the last request (reference request to
the results of a function) isn't really possible or
feasible, but the first three definitely are.

Another possible solution would be to throw an E_WARNING
if $_GET or $GLOBALS['HTTP_GET_VARS'] is used as the left-
hand side of an expression.  This would make changing 
information within $_GET or $GLOBALS['HTTP_GET_VARS'] 
officially frowned upon, which would have alerted me to the
fact that now in 4.1.1 there are two places where a GET/POST
variable can be named and changed.

Or, if $_GET/$HTTP_GET_VARS is detected as a left-hand side
expression, call _internal_UPDATE_REQUEST( $key, $value ), 
to keep all arrays in sync.

I wrote up some documentation about the $_* variables, which
I would appreciate it if someone more knowledgeable about the 
inner workings of the $_GET stuff could look over it and let
me know if there are any mistakes.  I release that 
documentation to the PHP group under the same terms of license
as the rest of PHP's documentation, so please feel free to
integrate it if it is a welcome addition.

I am not subscribed to this list (am using it through the news
gateway now), so I might not receive any responses.  I would
appreciate being CC'd any relevant discussion.

Thanks for everything so far, PHP rocks!  :^)

--Robert   ([EMAIL PROTECTED] / [EMAIL PROTECTED])

Thank you for your response.  I understand what the $_* arrays
are for, but I still disagree.  :^)

echo $_GET['blah'];
echo $HTTP_GET_VARS['blah'];
$HTTP_GET_VARS['blah'] = 'test';
function test()
{
  echo $_GET['blah'];
}
test();

Why is the array data separate?  There is no good reason, and
several bad reasons.

Good reasons to be separate:
  1) You might want $_GET and $H_G_V to be different
  2) [some random reason about internal PHP code]
  3) does $_REQUEST get updated if $_GET/$_POST is updated too?

Bad reasons to be separate:
  1) takes twice as much memory
  2) $_GET != $HTTP_GET_VARS after script execution begins
  3) does $_REQUEST get updated if $_GET/$_POST is updated too?

At the very least, this is a documentation bug because $_GET !=
$HTTP_GET_VARS should be mentioned at 

  http://www.php.net/manual/en/language.variables.predefined.php

Here is my stab at documentation for $_* vars.

"""
With the introduction of PHP 4.1.1 there are several variables
introduced which are guaranteed to be available in every
function, no matter what the ini settings are.  These variables
are: $_GET, $_POST, and $_COOKIE, and contain the same
information as their corresponding $HTTP_*_VARS arrays.

The other variable introduced is $_REQUEST, which is a merged
array of all GET/POST/COOKIE data.

SPECIAL NOTE:  Although the information contained in $_GET,
$_POST, $_COOKIE, and $_REQUEST is initially the same as that
found in $HTTP_GET_VARS, $HTTP_POST_VARS, and $HTTP_COOKIE_VARS,
changes in one array do not impact changes in any other array. 
It is considered a bug, hack, or workaround to *set* any value
in any of these arrays.  (do not use them as a left-hand-side in
any expression).  This will make your code more readable, more
maintainable, and more useful to other script authors.

Converting from older styles...
===============================

Assume that you have a script which takes a single parameter,
'blah'.

In global scope:

echo $blah;  => echo $_REQUEST['blah'];
echo $GLOBALS['blah'];  => echo $_REQUEST['blah'];
echo $HTTP_GET_VARS['blah']  => echo $_GET['blah'];
echo $GLOBALS['HTTP_GET_VARS']['blah'] => echo $_GET['blah'];

In function scope:

function demonstration()
{
  global $blah, $HTTP_GET_VARS;

  // 1: using global operator from above
  echo $blah;

  // 2: using array HTTP_GET_VARS from global scope
  echo $HTTP_GET_VARS['blah'];

  // 3: using no special functions
  echo $GLOBALS['HTTP_GET_VARS']['blah'];
}

function demonstration()
{
  // 1: no need to global the variable name
  echo $_REQUEST['blah'];
  // 1: also valid is:
  global $blah;
  echo $blah;

  // 2: no need to global _GET, it is automatically available
  echo $_GET['blah'];

  // 3: same as #1, no need to change
  echo $_REQUEST['blah'];
}

"""

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to