Yes I suppose... though that just sounds like a problem for a hash - keep track of the addresses you're snarfing and when you rebuild the code just (and I don't *think* that's a big just) put it back together the right way. I don't know how the code refs are stored I'm just commenting on the feasibility of getting at all the data in a code ref. From my perspective it's possible and isn't weird somehow.

I've been thinking that it would be interesting to walk the opcode tree and symbol table to enumerate everything and then see where the gaps are. ;-) It sort of addresses the same idea since that idea is implementable using pure perl - no C compiler required.

__SIG__
printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE

I don't doubt you could do it, but I think there are some hidden traps. Grabbing package and lexical variables is easy enough though.

For instance, just using stringified refs as hash keys wouldn't always cut it as the data could change between serialization of two seperate objects. What is the proper behavior? Personally I'd throw it in a warning in pod as a caveat but would someone else expect them to have the same value? I suppose you could just make it a serialization option.

I'd think you would have to go beyond padwalker though as you should probably grab all the pads in case you were freezing a recursive routine. I don't know enough about internals to know how hard it would be to set it up back to where it was. I believe there are also other stacks involved. It would be great if it could be done but I suspect there is a reason it hasn't been yet.

-Lee

"To be civilized is to deny one's nature."

Actually I would numify the reference since it's cheaper but that's not the point. That's not the major point here though - are you expecting the stored copy of the $Something to automatically reflect changes to the instantiated $Something? I wouldn't but then I don't use Storable so mayne that should be an expectation. From a cursory read of the documentation it looks like all the serialization happens at defined points - when you call store(). There nothing that says that an object being modified must also propogate that change back to the frozen copy anyway. The only way you get that behaviour is if you either put store() calls in your methods or tie the thing and just trigger on changes. Or something.

At that point you don't really care if the object changes between calls to store() - when it happens you either revive what you stored or make a new copy. The only caveat I'm thinking of is if your object shares something that doesn't exist inside of the object (a reference to something external) or if you've somehow given the same lexicals to more than one object. In that case the only sane behaviour for Storable is to proceed as if the lexical belongs only to the code ref being serialized. Beyond that is madness since you can follow a code ref and find the entire rest of the symbol table and then you just pick an arbitrary point to stop at. Anyhow, the simpler behaviour of serializing a code ref's lexicals with it isn't wild or crazy. It's just the behaviour for external references (which could be to anything) and then shared lexicals (say you created multiple closures in one block) that is. Perhaps I'm just odd but I wouldn't expect Storable to serialize external references since you don't know that the frozen $Something is going to have access to the external reference anyway. Perhaps this just means I'm defining "inside" to mean the contents of the object and it's lexicals (for code refs).

Or... maybe I'm just confused on where the object begins or ends since if I have one object consisting entirely of structures that are owned by that object (I suppose the definition for "own" is up the object's author) that's mostly clear. If another object also has data structures but those point back to some shared resource... then does the object own the thing it knows about?

Interesting idea anyway. Thanks for brining it up!

__SIG__
printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE