Rasmus, if you were arguing for adding a second class of session
variables which are always available through and looked up in
the global symbol table, you actually had a point. I
completely disagree though with your interpretation of the
outdated, unmaintained session_register() documentation.
> 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.
The accompanying commit message for this documentation change
says everything:
"Expanded docs on session_register(). If anyone wants to
rewrite it to bemore clear, feel free."
Especially note that the sentence you quoted _predates_ the
existence of $HTTP_STATE_VARS. The documentation of
session_register has unfortunately never been modified after
these were added.
Nevertheless, the implementation of the session module has
advanced and changed somewhat.
> Very simple. It says that the named global variable will become part of
> the session. [snip]
It is saying that, because at the time of writing,
session_register could not take it from somewhere else. Is
that so hard to accept?
> If register_globals affects this, then you have completely changed the
> meaning behind the register_globals switch. [snip]
Sorry, your complaint comes a few years too late.
> I see absolutely no inconsistency here and completely disagree with
> breaking BC for so many people on this point.
4.3 maintains BC by default.
- Sascha
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
