Re: session_register warnings

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