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

"Sascha Schumann" <sascha@schumann.cx> wrote... > Nope, I think you are missing the point of this discussion. > > In a given web site, you may have two or more areas which > coexist in one framework, but which are nevertheless > developed separately (so they do not share code which > accesses session objects). Users of this site can switch > between these areas smoothly, they use the same session in > all areas. 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. -- Matthew Kendall