So far as I know, in any object-oriented language (or approximation thereof), serialization only addresses the properties of the object, not the methods.

Also, I suggest that you should not expect that any “setters” (methods that are to be called when you store a value into some property) will be called, nor that “private” things which may be used by such getters/setters will be populated.

The problem here is that “a serializer” can be counted on only to serialize/unserialize a data structure.   But, an object is more than a data-structure.   An object, so to speak, moves.   When you push-and-prod an object, lights may flash and bells may ring.   Serializers can’t know anything about such things.   Even if they precisely restore the memory-areas corresponding to the object, they do not know what the object does.   Thus, they might not restore the true internal/external state of the object.

In practice, many object-oriented programs which I have encountered (not necessarily in Perl ...), which need to reliably serialize objects, do so, at least in part, using methods which are created for the purpose.   The object, itself, provides “a serialized representation of itself,” and, within another method, consumes it.   Anything which needs to be executed as part of the process of doing either of these things becomes, as it should be, the opaque responsibility of the object itself.