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."