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

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 > > > RL>> 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/ > >