Re: PHP 4.0 Bug #5152: Object passed in a session generateserrors when member functions are called
| From: | Bug Hunter | 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