> PHP 4.2 and earlier versions behave inconsistenly with regard
> to treating global variables as source of session variables.
> They work exactly like this:
>
> 1st request
>
> session_register('c');
> $c = 3; # Updates session variable
>
> 2nd request
>
> session_start();
> $c = 5; # Does NOT update session variable
>
> That is clearly broken under the assumption that
> session_register() should act on global variables. It
> clearly does not (always).
Ok, disregard everything else and let's just focus on this one statement
since it is the core of the disagreement. The way session_register() has
always worked and has been documented is this:
session_register() registers the global variable with that name in the
current session.
Very simple. It says that the named global variable will become part of
the session. Nothing else. It does not imply that this variable we have
injected into the session will always be available as a global or anything
else, it is simply a function that lets you take a global variable and put
it into the session.
If register_globals affects this, then you have completely changed the
meaning behind the register_globals switch. register_globals should have
absolutely no side-effects. It should be a simple and consistent switch
which only affects whether PHP's global symbol table is auto-populated or
not.
If register_globals is off, it is starting to sink in for people that they
will need to access variables through one of the autoglobal arrays and
that no variables will automatically enter the global symbol table.
Therefore it is quite consistent that they will have to get and modify
$_SESSION['c'] on the 2nd request.
I see absolutely no inconsistency here and completely disagree with
breaking BC for so many people on this point.
-Rasmus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
