Re: calling methods on deserialized objects
- From: "Mumia W." <mumia.w.18.spam+nospam.usenet@xxxxxxxxxxxxx>
- Date: Sat, 26 Aug 2006 04:00:48 GMT
On 08/25/2006 06:35 PM, Michael Küper wrote:
thanks for your reply ...
Mumia W. wrote:I've haven't used CGI::Session, but I don't think it'll work for two reasons:What "internal connection" are you refering to? As far as i know, an object is nothing more than a blessed hash reference!?
1) serialization and deserialization breaks the internal connection between hashes and their associated classes, and
Again, my entire previous post was a Wild A$$ Guess (WAG); take it with some grains of salt.
I imagined that invisible Perl bytecode establishes the connection between a hash reference and it's class. I was wrong, because I tried it with Data::Dumper and FreezeThaw, and it worked.
Note, I didn't use CGI::Session but instead stored the data in the __DATA__ section.
So the "connection" between hashref (object) and package (class) is the blessing (the packagename stored with the hashref), or am I missing something here? If there IS actually something more, this would explain the behaviour ...
2) after deserialization, objects referred to by references may be in different locations.This is not a problem (at least in my case). The serialized structure looks good (I had a look at the session text file), references are replaced by their serialized target, no memory address pointers inside ...
I have three bits of advice: 1) bless the hashes back into their respective classes after deserialization,they do have the correct class! (since ref($hashref) returns the correct name).
It should work, even without re-blessing.
2) use custom serialization and deserialization methods to reconstruct the object tree for each request, andwould be an option ...
but I still hope to find a way to use the default session deserializer.
3) make sure the objects' package (class) files are loaded before deserializing.This is something I thought of too ...
I will check, if this helps. But anyway: if the packages would not have been loaded, the "eval-way" of calling the method could not have worked, could it?
At least in PHP, storing objects in sessions doesn't work if the class definitions aren't loaded when the session data is loaded by the interpreter (AFAIR). Although Perl is a completely different language, the problem is (probably) the same. How can you associate an object's data with a class if the class' definition isn't loaded?
This post is a WAG so forgive me if I'm totally off the wall.I don't know what WAG stands for, but i forgive you in any case and thank you for your time :-)
PS.If there is some "internal bytecode" could you please give me a link to an explanation? Cause I didn't find anything like this in my perl book.
The ref() function returns a string of text and, by itself, is no indication that the internal bytecode that connects a hash reference to a class is still there.
kind regards
Michael
I can't test your program because you didn't post one.
Why don't you post a minimal but complete Perl script that demonstrates your problem, so you can get some responses that are better than WAGs :-)
.
- References:
- calling methods on deserialized objects
- From: Michael Küper
- Re: calling methods on deserialized objects
- From: Mumia W.
- Re: calling methods on deserialized objects
- From: Michael Küper
- calling methods on deserialized objects
- Prev by Date: Re: calling methods on deserialized objects
- Next by Date: Modules for hash functions? (ie, common algorithms for computing hash keys, not manipulating perl hashes)
- Previous by thread: Re: calling methods on deserialized objects
- Next by thread: Modules for hash functions? (ie, common algorithms for computing hash keys, not manipulating perl hashes)
- Index(es):
Relevant Pages
|