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

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. > 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. - Sascha