| Author |
stange behavior of $_SESSION
|
|
| Peter Pei 2008-01-06, 10:04 pm |
| With a usual (well bothing should be unusual) array,
$a[] = "a"; $a[] ="b" sets the first two elements of the array.
I expect somthing like this to work in exactly the same way:
start_session();
$_SESSION[] = $_POST["a"];
$_SESSION[] = $_POST["b"];
So what I meant is that run this page, PHP should set the first 4 elements,
but what actually happened was the second round overwrites the first one,
and the array ends up only have the first 2 elements set.
| |
| Janwillem Borleffs 2008-01-07, 3:59 am |
| Peter Pei schreef:
> With a usual (well bothing should be unusual) array,
> $a[] = "a"; $a[] ="b" sets the first two elements of the array.
>
> I expect somthing like this to work in exactly the same way:
> start_session();
> $_SESSION[] = $_POST["a"];
> $_SESSION[] = $_POST["b"];
>
> So what I meant is that run this page, PHP should set the first 4
> elements, but what actually happened was the second round overwrites the
> first one, and the array ends up only have the first 2 elements set.
>
The $a[] = 'value' approach only works when $a is an indexed array. The
$_SESSION array is associative, meaning it works with keys and values.
The following will work as you expect:
$_SESSION['key'][] = $_POST["a"];
$_SESSION['key'][] = $_POST["b"];
Now you can do $_SESSION['key'][index] to retrieve the appropriate value.
JW
| |
| Peter Pei 2008-01-07, 7:01 pm |
| This explanation is not good enough.
PHP arrays are mixtures of indexed and associative? Two things:
1) There is no way to define/declare an array as associative or indexed, as
far as I know.
2) Something like this works:
<?php
$a["a"] = "a";
$a["b"] = "b";
$a[] = "c";
$a[] = "d";
var_dump($a);
?>
This gives you the following as expected:
array(4) {
["a"]=>
string(1) "a"
["b"]=>
string(1) "b"
[0]=>
string(1) "c"
[1]=>
string(1) "d"
}
Why should $_SESSION be different?
| |
| Janwillem Borleffs 2008-01-07, 7:01 pm |
| Peter Pei schreef:
> Why should $_SESSION be different?
>
Basically for the same reason $_POST[] doesn't work either: The key is
used to set/retrieve the associated value, it's as simple as that.
Also note that the key shouldn't be numerical value...
JW
| |
| Janwillem Borleffs 2008-01-07, 7:01 pm |
| Janwillem Borleffs schreef:
> Basically for the same reason $_POST[] doesn't work either: The key is
> used to set/retrieve the associated value, it's as simple as that.
>
> Also note that the key shouldn't be numerical value...
>
Your reaction to this is probably that the restrieval can also be done
by an index. If you look at a typical session file, you will see why you
need to use a string as the key to identify your data.
JW
| |
| Peter Pei 2008-01-07, 7:01 pm |
| The fact is that $_SESSION[] = "a"; $_SESSION[]="b"; works - works on the
initial page when it is set up.
The problem is that the values are not retained on the next page. There is
some other reasons behind, not what you have said.
Who told you that you cannot do $_POST[] = "abc"? It clearly works. You
didn't grasp the original issue: the issue is not whether [] works for
$_SESSION, but why the indexed values are lost next entry of the session.
| |
| Janwillem Borleffs 2008-01-07, 7:01 pm |
| Peter Pei schreef:
> The fact is that $_SESSION[] = "a"; $_SESSION[]="b"; works - works on
> the initial page when it is set up.
>
This works on the initial page, because all you're doing is updating an
array. It doesn't work on the second page because PHP can't write it to
the session file due to its format.
> Who told you that you cannot do $_POST[] = "abc"? It clearly works.
It only works under the same conditions applying to $_SESSION, but you
cannot assign data from a form this way.
JW
| |
| Peter Pei 2008-01-07, 7:01 pm |
| To make the question more clear. Try this piece of code:
<?php
session_start();
$_SESSION[] = rand();
?>
<html>
<body>
<?php
print_r($_SESSION);
?>
</body>
</html>
Refresh the page couple of time, you will see that the index is not
increasing. I believe this is more a design choice in session_start, or a
plain bug. If it is a design choice, I would like to know the reason if
anyone knows.
Please don't reply if you don't know the answer.
| |
| Peter Pei 2008-01-07, 7:01 pm |
| There is no reason why a better serialization cannot be done.
| |
| Peter Pei 2008-01-07, 7:01 pm |
| The $_POST talking is meaningless any way, I merely continued from your
taklking.
You are simply saying that the format of the session file is bad - not even
be able to support some basic serialization. I take that as an answer, and
that's what I guessed.
| |
| Peter Pei 2008-01-07, 7:01 pm |
| PHP should be able to support any kind of session data.
| |
| Michael Fesser 2008-01-07, 7:01 pm |
| ..oO(Peter Pei)
>The fact is that $_SESSION[] = "a"; $_SESSION[]="b"; works - works on the
>initial page when it is set up.
It doesn't work. Configure your error_reporting directive how it should
be to E_ALL|E_STRICT and you'll get some notices:
Notice: Unknown: Skipping numeric key 0. in ...
Notice: Unknown: Skipping numeric key 1. in ...
>The problem is that the values are not retained on the next page. There is
>some other reasons behind, not what you have said.
Numeric keys are not allowed in the $_SESSION array. There's also a bug
report regarding this issue, even if it doesn't really clear things up.
http://bugs.php.net/bug.php?id=42472
So for an exact reason you would have to ask the PHP dev team. One
possible reason I could imagine comes from the old register_globals
days. With this directive enabled session variables were also
automatically populated as variables in the global namespace, but
variable names starting with a digit are not allowed.
Micha
| |
| Peter Pei 2008-01-07, 7:01 pm |
| First of all it works, read my reply to my own original post. There is a
clear example. Whether it shows warning message or whether it stops working
in a more strict mode, that is a totally different topic.
Second half of your answer is interesting. So it might be a restriction from
old days. That's why a language should be well designed to begin with. It is
really hard to patch up later. Perl is a clear example of such failure.
| |
| Peter Pei 2008-01-07, 7:01 pm |
| Forgot to mention. That bug report was more about the warning message and
whether it is intuitive or correct, which is not my concern.
| |
| Michael Fesser 2008-01-07, 7:01 pm |
| ..oO(Peter Pei)
>First of all it works, read my reply to my own original post.
Depends on how you define "works". If you just mean that you can add
numeric indexes to the $_SESSION array, then you're right, this works.
But it doesn't really do what you expect from it, the behaviour is more
or less undefined and throws a notice.
>There is a
>clear example. Whether it shows warning message or whether it stops working
>in a more strict mode, that is a totally different topic.
I don't consider code that throws notices working. I consider it buggy.
The error in your code was there right from the beginning, it was just
not shown because of an improper error_reporting setting.
>Second half of your answer is interesting. So it might be a restriction from
>old days.
That was just a wild guess.
>That's why a language should be well designed to begin with.
Sure, but PHP was never meant to become what it is today. It's a
language grown up from a collection of small Perl scripts, with all the
benefits and drawbacks this approach brings along. There are exactly two
ways to deal with this:
1) Learn how to live with it.
2) Use another language.
>It is
>really hard to patch up later.
Correct. But that's how it is and we have to accept that. Over the years
the PHP dev team has done a lot to clean things up, remove deprecated or
broken features and make the language more consistent. PHP 5 has brought
a lot of improvements, and so will PHP 6. But such things take time and
don't come overnight.
Micha
| |
| Michael Fesser 2008-01-07, 7:01 pm |
| ..oO(Peter Pei)
>Forgot to mention. That bug report was more about the warning message and
>whether it is intuitive or correct, which is not my concern.
Correct, now that you say it ... should've read more carefully.
Micha
| |
| Peter Pei 2008-01-07, 7:01 pm |
| Learn how to live with it, that's true. But critics still needed. Just like
watching a movie, regardless how bad or good it is, you still comment what
can be made better.
Side note. About your warning message... I didn't test, but it is possible
that it only shows up when the page is refreshed, and the initial load never
cause any warning... Not sure, take a close look though, I may also do so
later if I am still interested.
| |
| Peter Pei 2008-01-07, 10:01 pm |
| Your guess was right and that's the reason. Hopefully this restriction will
go away down the road.
|
|
|
|