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: > > > > > > > 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. > > If a user defines a class after the deserializer did, Zend > will output "Class foo was defined twice." How do you propose > to fix that? When the class/object is deserialized, if it is not already defined, throw an error at that time. Right now, it just changes it to stdclass and goes on. > > 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. > > While your proposal exactly solves my constructed scenario, > I'd prefer a broader approach to this problem which avoids > any unnecessary complexity (and changes in the session user > interface). We already have two proposals which limit their > impact to the serializer (in ext/standard/var.c) and which > are transparent to the end-user. > > - Sascha But they hide the fact that the class isn't defined. What if my intention is to actually use that class object, but I fogot to include the appropriate file before deserializing. That is an error in the logic of my script, and I should be warned of such an error. Here is another idea, that would fit in with either of the other proposals. A new function session_options(flag). This can take flags that set various options. There would be a default behavoir defined via ini file, as defined by one of the previous proposals, if the function is not called. You could set options such as: WARN_UNDEFINED, HALT_UNDEFINED, IGNORE_UNDEFINED. WARN_UNDEFINED will simply do a E_NOTICE message, HALT_UNDEFINED would print E_ERROR message, IGNORE_UNDEFINED will pass the undefined objects through. This way, for development you can set the initial behavoir to HALT_UNDEFINED, and in your script, when you know you dont need an objet, call session_options(IGNORE_UNDEFINED). We now get the best of both worlds, error messages when needed without changing the current session functions. Shane