Re: PHP 4.0 Bug #5152: Object passed in a session

On Fri, 23 Jun 2000 php4@developersdesk.com wrote: > Addressed to: Bug Hunter <bughuntr@one.ctelcom.net> > php-dev@lists.php.net > > > > And I repeat. My main point here was to maintain a connection between the > > > class definition and the object data. That would make it possible to > > > autoload them or provide user controlled loading without needing to keep > > > track of which file might define which class. > > > > > > -Rasmus > > > > I agree. I would carry it farther, and allow the functions to be > > serialized totally, so that the text or opcodes made it in with the > > data. However, that is details. > > > > > You are aware that keeping the code with the data means storing a > _separate copy_ of the code for each and every session that is in > storage, right? For long duration sessions on big sites, that could be > hundreds or even thousands of copies of the object method code in > session storage. > > What a waste! <snip> I either mis-understand what you are saying, or I don't agree with you. If you _must_ serialize the entire session in-situ, then you are right. I honestly had not considered the session situation, and the approach of serializing the entire object, methods and all, as duplicates, and as the _only_ way. I was thinking of a database repository of objects that you could serialize into and deserialize from for purposes other than a session. However, if you get the option to either serialize only the data, or the whole method when doing the serialization, then we would both be happy. A session could deserialize only the data. A user could deserialize an entire object for their own purposes. Possibly, a session recovery could deserialize a global object, and then deserialize the data from the unique storage for the session. If the only reason you are doing data serialization is for session support, you are absolutely correct. There would be too much waste involved for hundreds of users. I had in mind only one copy of an object deserialized for hundreds of users, with data filled in from another location. bug