phplib's solution has been to re-register s globals ll the $_SESSION
vars.
The register_globals=Off has been placed, I suppose, to prevent GET/POST
(and any user_originated) var to overwrite uninitialized program
variables.
As session vars are not user_originated, and only the programmer can set
Sascha,
What I, at least, fail to understand is the answer to Rasmus' initial
question(s):
- Are we going to break compatibility? If not, then why are we spitting
out this error by default?
Given what I've seen here in the last few days, I think it's fair to say
that this notice will cause
On Sun, 13 Oct 2002, Zeev Suraski wrote:
Sascha,
What I, at least, fail to understand is the answer to Rasmus' initial
question(s):
- Are we going to break compatibility? If not, then why are we spitting
out this error by default?
If you have followed the exchange, you will have
At 11:06 13/10/2002, Sascha Schumann wrote:
On Sun, 13 Oct 2002, Zeev Suraski wrote:
Sascha,
What I, at least, fail to understand is the answer to Rasmus' initial
question(s):
- Are we going to break compatibility? If not, then why are we spitting
out this error by default?
If
I have followed it, even though I don't recall ever seeing a clear-cut
statement to that extent.
It is very likely that you are missing the central issue here
as well. Please see the example as posted by Rasmus
http://news.php.net/article.php?group=php.devarticle=89364
and
Sascha, would you mind explaining the reasoning for changing this
behaviour? Whether it is documented or not, I'd like to hear a technical
reason for not allowing session_register() to act on global variables when
register_globals is off. I still don't see it. All I see is
inconsistency here.
On Fri, 11 Oct 2002, Rasmus Lerdorf wrote:
Sascha, would you mind explaining the reasoning for changing this
behaviour? Whether it is documented or not, I'd like to hear a technical
reason for not allowing session_register() to act on global variables when
register_globals is off. I still
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
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
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?
It is hard to accept because the function has
With PHP 4.3, it finally becomes possible to completely
manage session variables without any dedicated functions.
Just set or unset variables in $_SESSION and you are done
with it. It could not be any easier.
The streamlining of the serialization process also has
another
With PHP 4.3, it finally becomes possible to completely
manage session variables without any dedicated functions.
Just set or unset variables in $_SESSION and you are done
with it. It could not be any easier.
And that's very nice. I have no argument with that.
The
Now I'm not really anyone special - just another user, as it were, but I do
use the session module on a daily basis as part of my job. FWIW, I agree
with Sascha on this one. A user should be able to work with a session
variable in global scope all the time, or not at all. Not some mish-mash of
I'd like to do a collective rethink of this. The simple description of
the session_register() function in the manual is:
This description was correct initially (I wrote it), but has
not been updated as the session module was extended. I've
noticed this documentation issue in the
On Wed, 9 Oct 2002, Sascha Schumann wrote:
I'd like to do a collective rethink of this. The simple description of
the session_register() function in the manual is:
This description was correct initially (I wrote it), but has
not been updated as the session module was extended.
Unless we're missing some problem I agree with Rasmus here.
I don't see much advantage in changing this.
Of course, there might be a reason
Andi
At 10:40 AM 10/9/2002 -0700, Rasmus Lerdorf wrote:
On Wed, 9 Oct 2002, Sascha Schumann wrote:
I'd like to do a collective rethink of this. The
At 10:40 09/10/2002 -0700, you wrote:
I am not talking about just mine. I am talking about a sizeable subset of
all PHP apps that use sessions. My problem here is that I do not
understand the reasoning for not continuing to allow session_register to
work on global variables regardless of the
On Wed, 9 Oct 2002, Gareth Ardron wrote:
At 10:40 09/10/2002 -0700, you wrote:
I am not talking about just mine. I am talking about a sizeable subset of
all PHP apps that use sessions. My problem here is that I do not
understand the reasoning for not continuing to allow session_register
18 matches
Mail list logo
