Re: Sessions and Object Revisited

The deserialization of php's "object" type was redone since 4.0 Release. I'm about to see if this problem is fixed. If not, there looks to be a (fairly) trivial fix to the deserialization method that would allow for the methods to be retained. (it's in CVS as /ext/standard/var.c - the latest is v165, the original 4.0 Release version is 1.56) I'm also going to write a method to allow explicit loading with a build-flag. The build=flag will enable either auto-loading of all variables or explicit loading of only the variables you call the new method against. Now I just need to figure out all of the PHP macros...wow. While macros keep the code "clean" visually after you know them, they are a PITA when you're trying to figure all of them out. -Szii/Mike At 10:17 AM 6/19/00 -0700, James Du Russel wrote: >Wow, quite a thread I caused there. > >After having a weekend to mull this over, I came up with a few things. >I don't have the time right now (project deadline coming up) to try and >learn how to change the internal workings of php. If I could, I would >make classes that are unserialized retain their class name, but alias >the class name to stdClass. Then again, I really don't know how >feasible this is. > >I came up with a couple of userland solutions. > >1. The more elegant way would be for me to write another session >library specifically for objects, which told the system which objects to >serialize into a session registered array, and when to unserialize >them. This meaning that a page that didn't explicitly ask for an object >to be unserlized would leave it nestled away in it's array of scalars, >type untouched. > >2. The quick and dirty way would be to create a stub file. Since every >class I define is defined as a separate module, and each module adds >itself to an associative array, I test to see if the module has been >loaded, if not, I define a stub class. This is done after all my other >modules load, and before I restart the session. > >I went with option two, because it took me only a few minutes to cook >up. I'll cook up option one when I'm not working under such a close >deadline. > >The reason I don't want to include every file into each page is simply >performance. The project I'm working on is _extremely_ complex, half of >it is in perl, half in PHP. (I had to make the two talk to each other) >I can't very easily decide what object can be unregistered either, >because there is no clear path through the system. > >I would still like to see a function that can cast an objects variable, >but if I have to write it, eventually I will. (See other comments re >time.) =) > >Thanks to all of you for your time and input. > >James > >-- >PHP General Mailing List (http://www.php.net/) >To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net >For additional commands, e-mail: php-general-help@lists.php.net >To contact the list administrators, e-mail: php-list-admin@lists.php.net > > >