Re: calling methods on deserialized objects



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:
1) serialization and deserialization breaks the internal connection between hashes and their associated classes, and
What "internal connection" are you refering to? As far as i know, an object is nothing more than a blessed hash reference!?

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, and
would 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.
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.
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.

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 :-)

.



Relevant Pages

  • Re: calling methods on deserialized objects
    ... serialization and deserialization breaks the internal connection ... is nothing more than a blessed hash reference!? ...
    (comp.lang.perl.modules)
  • serialization inherited objects
    ... deserialization. ... Some extra propertys in the objects ... Now I would like some solution will the serialization keeps working. ... that in my app I would like to keep using my original name ...
    (microsoft.public.dotnet.languages.vb)
  • Re: cannot use static fields in AJAX applications?
    ... type's assembly is sufficient to resolve additional types. ... serializer construction for specific types. ... ViewState's built-in serialization does not like dynamically constructed ... serializers for later deserialization requests. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Serialization woes
    ... > serialization of an object (i.e. by implementing the ... > object and the call to the special constructor. ... its elements *until* deserialization is complete - ... aknak at aksoto dot idps dot co dot uk ...
    (microsoft.public.dotnet.languages.vb)
  • RE: ObjectManager Problem - Plea for help!
    ... RegisterObject() should be - as the documentation for RegisterObject says - ... The problem is that during deserialization I don't know that C2.m_s is the ... constructor required for custom serialization allows there to be a level of ... the formatter code would need to change to: ...
    (microsoft.public.dotnet.framework)