Re: [PHP4BETA] class serialize/unserialize implementation.

At 14:38 16/09/1999 , Stig Sæther Bakken wrote:

Andi Gutmans wrote: At 01:23 PM 9/15/99 +0200, Thies C. Arntzen wrote:

hi - the problem i see is that you *NEED* to have the class your unserializing defined *BEFORE* you can unserialize i't instance - even though it seems logical i don't know if people will get bitten by this! the benefit is that you get a fully working instance fron unserialize instead of the "dumb" array you got in PHP3 also 'cause i had to put the class-name into the serialized data. it probably won't "unserialize" when using php3. (people that store serialized data in a file/db may get bitten by this!). the next time we come up with a new format (i hope never!) we need to make sure that we have a version number and a magic-cookie - so that we can mark incompatible changes! comments?

Only comment I have is the obvious. Serializing the class name is definitely the way to do it. People have to be disciplined enough to have the class defined before the call to unserialize. Andi, the Zend feature list mentions run-time binding of function names. I assume this means that it is easy to implement some auto-loading mechanism. If Zend had run-time binding of class names too, object serialization would become child's play. I have no idea of what I'm asking though :-)

Well, it's very easy to implement this at the 'application' level. You could instruct people to store their class definitions in .pclass files. Then, when you unserialize an object of type ClassName, and ClassName is not serialized - you can check for ClassName.pclass, and try to execute it (unlike PHP 3.0, it's trivial to compile&execute a file in PHP 4.0 with no need for any special effects). Then you try to find the class name again. This implement transparent autoloading at the unserialize() level. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/ For a PGP public key, finger bourbon@netvision.net.il