On Sat, Aug 16, 2008 at 10:06 AM, Stut <stuttle@xxxxxxxxx> wrote: > 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. > > 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! > > -Stut > > -- > http://stut.net/ Just to add on a thought... The session extension is a global variable. We should make sure our applications play nicely with any other piece of code. We do this by prefixing our functions and classes with something to fake namespaces. The same ideas carry over to any other global construct. So at the very least if I am using the session class I will have $_SESSION['appname'] as my base. Same goes for $GLOBALS, etc. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
