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

RL>> into PHP. I really don't see why it is a bad idea to tie object data to RL>> its originating class definition. This doesn't mean that it will Because it's against the purpose of the classes. You could as well just read all the class definition and carry it along with object as a property. But nobody in good mental health would do that, I hope. RL>> O:3:"foo":"file://foo.inc":1:{s:1:"a";i:124;} RL>> RL>> where file://foo.inc is a resource that would have the class RL>> definition. But having the option to also bundle it with the class Well, and how *this* would bloat the serializer? And why all this? If you know foo.inc, why won't you include it anyway? Because somebody's too lazy? Well, too bad. RL>> definition also seems like a useful thing to me. The argument that nobody RL>> else does it this way doesn't really convince me that it is wrong. If it Yeah. One has to build one's own square wheel to understand why all others build round wheels. I see. RL>> makes life easier for the user, and it is more flexible, then I don't RL>> really care what conventions dictate. Especially because he deserializer RL>> could optionally choose to use the embedded class definition or not. Deserializer could do everything including generating class definitions on the fly from IDL templates. I just don't think it needs to. If you want to implement on-demand class loading, you are welcome to. That actually might be interesting feature. But certainly it shouldn't shove it into deserializer, though deserializer could use it. On-demand loading could indeed be useful, though I imagine there could be some problems with it (if there are more than one class in the file). But certainly this has absolutely nothing common with shoving class code into object definition. -- Stanislav Malyshev stas@zend.com +972-3-6139665