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

Bah. I'm a moron. Reading farther into Storable it already describes it's strategy for shared things. It doesn't unless you you pass in the other things that care about the shared thing. So all that blather about references and lexicals is already solved (or the strategy is defined anyway). I fall back to my original question that I don't see what the big deal is. I may still be a moron but at least I think I'm asking in the right area.

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

I don't think it's impossible. I just think there are probably a lot of little issues to get it to work in the genreral case so that you don't even have to think about it, it just works. I've done similar things with PadWalker but they wouldn't work in all cases and the subs had functions that had to be explicitly called to restore state.

One point about using a hash for the references, no matter what you use they end up being strings from my understanding as they are automatically quoted.

-Lee

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