Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called

From: Date: Thu, 22 Jun 2000 16:59:01 +0000
Subject: Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
References: 1 2 3  Groups: php.dev 
Request: Send a blank email to php-dev+get-21971@lists.php.net to get a copy of this message
On Thu, 22 Jun 2000, Matthew Kendall wrote: > I've been following this discussion with interest and I had an idea I wanted > to share. > > In the above situation, if the areas are developed seperately there is more > than just the problem of class definitions. What if both developers decice > to use a variable called $foo, and serialise it? We have a name conflict. > > Here is my idea. Divide sessions into seperate namespaces. There is one > namespace called Global. If you don't specify a particular namespace when > you add a variable to a session it gets put in the Global namespace. You > would use this for variables needed on all pages of a site, and you would > expect to define all associated classes on each page. All variables in the > Global namespace are automatically de-serailised at the start of a session. > This gives complete backwards compatibility. > > But you could also define arbitrary namespaces within the session. Say > Calendar and Todo. The person writing the Calendar part of the site > specifies the Calendar namespace when she puts variables into the session. > The person writing the Todo list part of the site specifies the Todo > namespace. These namespaces are not automatically de-serialised at the start > of the session. You have to explicitly ask for them with a new function, say > retrieveSession('Calendar'). You are expected to include all associated > class definitions before doing this, but you only have to define the classes > for the variables you put in your namespace. You can be entirely unaware of > all the other namespaces. > > You might say, about the $foo example above, that the developers should have > just agreed to have used $calendarFoo and $todoFoo, but this is just > implementing namespaces in a kludgy, manual way. Better to do it properly. > > I haven't looked into the details of this and I am not an expert on > sessions, but I wanted to share this idea because it seems so nice. I'm sure > it could be made backwards compatible, and it seems to me to solve peoples > problems. I actually like this idea. Something to think about though is whether to use one function session_namespace() that would set the namespace for saving/retrieving sessions or to use a manual session namespace retrieval like you mentioned. Another problem might be what to do if both Global and Calendar namespaces have the same variable - what overrides what. -Andrei Programming X-Windows is like trying to find the square root of pi using roman numerals. - Unknown

« previous php.dev (#21971) next »