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

I disagree and most of the globe disagrees too. An object should be serialized according to its members and it should not include the methods. You are trying to find a solution to a very simple problem. If someone is coding a PHP application why wouldn't he just include() the class definition when he needs it? Not that I don't want to make a coders' life easier but I really think that someone who's coding OOP has a good enough background to know that he needs the class definition before he unserializes an object of that class. Every OOP language I have encountered and used works this way. I don't think we should go out of our way to help the odd joe shmoe coder who can't handle this situation. If we start serializing the class definition you'll have a zillion of real OOP coders who come and complain about their database overflowing because every object he serializes to the database is huge. It really seems to me that everyone is looking for a way to help 3% of the coders while screwing 97% of the others. And no, I don't want it to be user-definable because it should be consistent for everyone. Andi At 02:42 PM 6/22/00 -0700, Rasmus Lerdorf wrote:

Whatever the convention might be, it would seem useful to me to be able to keep the definition with the data. It's like passing simple data along without specifying whether the data is supposed to be an integer or a string. Our current serialization passes the type definition along with the data. i:123; for example. In this case the complete class definition for the 123 object happens to be very simple. It says that 123 is an integer object. For more complex objects the class definition would also be more complex, but I don't think it would be inconsistent. -Rasmus On Fri, 23 Jun 2000, Andi Gutmans wrote: It is common practice to only serialize object data and not methods in most programming languages and environments. It makes sense and there is no reason the person using the unserialized object wouldn't have access to the object definition. If you really want to pass the class hierarchy itself too then just pass the definitions as text and let the person eval() it although I think this is not the right thing to do and he should and would have the class definitions handy. Andi At 04:26 PM 6/22/00 -0500, Bug Hunter wrote:

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 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/ -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net

--- Andi Gutmans <andi@zend.com> http://www.zend.com/