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

Sascha Schumann wrote: > > On Wed, 21 Jun 2000, Shane Caraveo wrote: > > > > We agree on: > > > > > > - PHP needs to preserve the name of the class of a > > > serialized object, even if the class definition is not > > > available during deserialization. > > > > Why agree on that? > > > > > We do not agree on: > > > > > > - PHP must stop script execution and output a misleading > > > error message, if the script defines a class and if this > > > class was absent on one or more object instantiations. > > > > Why not agree on this? > > Because throwing a misleading error message is not > appropiate. The mailing lists are full of recurring > questions. We want to avoid that. Missleading errors are fixable, to provide more acurate error messages. > > The problem is, php is trying to be TOO SMART(TM) in how it handles this > > situation by changing the class to stdclass, so that my script doesnt > > break because I was too brainless to include the appropriate file(s) > > prior to unserializing my data. Ease of use is one thing, but second > > guessing what I am trying to do is another. > > > > Throwing an error that says "ERROR: unserialized class XXX not defined" > > would let me know that I need to include the file that defines that > > class. You can also then do away with the stdclass thingy. This error > > can be thrown from the unserialize function instead of having that > > function change it to stdclass. > > 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. > > With your proposal, all areas would have to include all class > definitions of all areas. I don't think that is sensible. Ok, I can see the issue of having seperate development needing to share session variables. So provide a way to set and request multiple session "parts", rather than getting the entire session in one shot. That way, you can request only those parts a particular page needs, and thus avoid any work around for dealing with this at all. At the same time then, if a class is requested that code does not exist for, then you can error out. You could do something like: include("myclass.inc"); include("anotherclass.inc"); $sid = session_get_id(); $myclass = new MyClass; $anotherclass = new AnotherClass; session_addvar($sid, $myclass, "MyClass"); session_addvar($sid, $anotherclass, "AnotherClass"); // etc. etc. Then another page later: include("myclass.inc"); $sid = session_get_id(); $myclass = session_getvar($sid, "MyClass"); Now we've avoided two issues; one being that we dont want to include everything everywhere, two that we require code for the requested class to exist, and can provide an appropriate error if the code for the class does not exist. The session var containing 'anotherclass' need not be touched at all unless it's requested by a page. It could be optimized futher, just use one function for the vars: session_var($sid, $myclass, "MyClass"); This would either get the session variable "MyClass", or create a new one, in either case assigning it to $myclass, and registering the class to be serialized at the end of the request.