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

From: Date: Thu, 22 Jun 2000 21:26:36 +0000
Subject: Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-21987@lists.php.net to get a copy of this message
On Fri, 23 Jun 2000, Stanislav Malyshev wrote: > RL>> Is there anything stopping us from optionally including the class > RL>> definition in the serialization? Wouldn't that make all this go away? > > Yes there is. > 1. THis is plain wrong. Class should be defined by user in PHP, not > carried along in sessions. > 2. How exactly you are going to carry class members, methods, etc., > etc? And why exactly do you need it? > 3. And now the fun thing. Imagine derived class. Now you've got to bring > along all the class tree up to the root with you. Fun, fun, fun. I disagree. I understand your point, and I can see your problems. The problems behind PHP make it too big a project for me, overall. I would never have tackled it. However, a whole new market opens up if you can deserialize objects in toto, including the code. With that feature, you can now sell a compact set of classes to the masses. You can also cause classes to be loaded with slightly different features (partly due to the inheritance feature that you cringed at), depending upon computation decision trees, at run time. of course, you can now do this with #include and if() statements. However, it is additional files, and not nearly as nice as deserializing from a database. Much less secure, too, based on generic observations of web site directories at different companies. (Note that all generic observations are incorrect by definition. There are always exceptions.) If doing it deserialization from an SQL database, using a BLOB would make it simple to load/unload such things. And the memory requirements and space requirements are _no_ different from #includes. Actually, the requirements may be somewhat less, as serialized data may or may not be compressed. Because of this, I would vote for serialization of an entire object, code and all. You can make it a php programming requirement to serialize the parent objects first or last when storing objects into a database. (Whichever works out better during deserialization.) The one thing that it does give rise to is VIRUSES, as many PHP programmers would be willing to pick up code and run it without checking. However, the same argument applies to #includes. bug

« previous php.dev (#21987) next »