Sascha, could we revisit these session changes?  I stuck current head on a
server that runs all sorts of PHP code written by a bunch of different
people.  These warnings were everywhere:

  Warning: Your script possibly relies on a session side-effect which
  existed until PHP 4.2.3. Please be advised that the session extension
  does not consider global variables as a source of data, unless
  register_globals is enabled. You can disable this functionality and
  this warning by setting session.bug_compat_42 or session.bug_compat_warn.
  in Unknown on line 0

I'd like to do a collective rethink of this.  The simple description of
the session_register() function in the manual is:

 session_register() accepts a variable number of arguments, any of which
 can be either a string holding the name of a variable or an array
 consisting of variable names or other arrays. For each name,
 session_register() registers the global variable with that name in the
 current session.

Now, there are further caveats about register_globals further on, but I
would like to propose that we kill any and all such caveats and simply
make the function behave exactly as described in the short description.
Don't make its behaviour change based on register_globals or anything
else.

I don't see why calling session_register('a') should not register the
global variable named $a in the session if that is what this function has
always been documented to do, and in fact has always done regardless of
the register_globals setting.  What is the drawback here?  I think the
analogy to this is changing PHP such that you cannot do $a=1 to set a
normal global variable when register_globals is off.  This obviously
doesn't make any sense.  register_globals determines which things are
injected into the global namespace, it does not determine whether we have
a global namespace or how normal function interact with this global
namespace.

Basically my points are:

 1. session_register('a') registering a global variable makes sense
 2. changing this breaks BC

-Rasmus


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to