At 3:06 PM +0100 8/16/08, Stut wrote:
Not really, since I would never name a session variable 1, or 2, or
5318008 - I would always put those in the session in a named array.
That's understandable. But, if you came from a background that
predated associate arrays, then using numeric indexes would seem more
natural. To me arrays come in two types, those with numeric indexes
and those with string indexes. I use both.
I wish I understood the reason why it's like this but I've never
looked into the session extension in that level of detail, but I
doubt such a limitation would exist if there was not a very good
reason for it. But again, I don't see how this is relevant.
I never said it was relevant.
I am sure too that whatever the reason was, it made sense at the time
and for the problem of the time -- similar to the a1 < z discussion
of a couple of years back.
It's natural to me to see the session array as a filing cabinet. At
the top level you would have files with names that indicate what
they are. Within each file it may be further divided into numbered
sections. Given that I can't see into the future, even if I
currently only have one set of data (file) to store in the session
(the filing cabinet) I wouldn't just chuck the bits of paper from
the file into the filing cabinet. I'd leave them in the file such
that when I need to add a new file I don't need to gather up all the
other bit of paper into a single file to get it organised again.
Ok, that didn't quite make it as clear as I wanted it to but I hope
it illustrates the point I'm trying to make. The root level of the
session array (IMHO) should contain descriptive keys, and I've never
been in a situation where 5318008 is descriptive and gives context
to the data unless you turn it upside down!
I understand what you are saying -- semantics are important. But if
there is a need for temporary place to store values I don't consider
it bad form to store them in a numerically indexed array.
For example, if a user was going to purchase up to 10 items, I see
nothing wrong is using:
user_purchase[0] = $item0;
...
user_purchase[9] = $item9;
And as such, one can easily extract what the user purchased by simply
using for().
However, in this case I don't see the gain provided by using:
user_purchase['item1'] = $item0;
...
user_purchase['item9'] = $item9;
But that distinction would be required IF you were using SESSIONs.
And that's one of my points -- normal arrays come in two types and
the SESSION array don't.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
