in reply to Re:(4): •Re: Upgrade B::Deparse?
in thread Upgrade B::Deparse?

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

Replies are listed 'Best First'.
Re: Re: Re:(4): •Re: Upgrade B::Deparse?
by diotalevi (Canon) on Oct 03, 2002 at 18:26 UTC

    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

[reply]
[d/l]
      It matters if you're trying to save and restore something like this: 
      sub return_getter_setter {
  my $value = shift;
  (sub { $value }, sub { $value = shift });
}
my ($getter, $setter) = return_getter_setter(42);

      [download]
      If I save both $getter and $setter in the same batch, I'd expect that when they are restored, they still both share the same secret lexical. I do believe that the current code deparser cannot be used for this at the moment, and that it's a difficult task. The problem is that when you deparse the text for $getter, you have to put some placeholder for $value, and when you deparse $setter, you still have to put some placeholder for that $value. But how do you know the two share the same placeholder?

      -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
Re: Re: Re:(4): •Re: Upgrade B::Deparse?
by shotgunefx (Parson) on Oct 04, 2002 at 07:26 UTC
    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."
[reply]

      You are misunderstanding me about the hash but that's ok since I'll take your word for it that there are many tricky little things that just aren't visible to me right now. All I meant by the hash was so that you could compare the addresses of two variables to see if it was the same one being referred to twice. Anyhow... I suppose I'll drop it unless I feel like just patching B::Deparse myself.

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

[reply]
[d/l]
        Regarding the hash references..
        "Actually I would numify the reference since it's cheaper but that's not the point."

        I took this to mean that you would be comparing references (numbers) instead of strings. If you use a hash for a key for remembering what data you have processed, then the key gets stringified, what I wasn't thinking was that the values of the keys wouldn't be stringified and that's what you would be comparing. slaps($self).

        As far as taking my word on the diffculties, don't take my word for anything. I don't know enough about internals but I think if it was that easy we would have had it a long time ago. Personally I'd like to see it. Very handy. One of the reasons I am trying to get into internals is to figure out how to implement coroutines and such. Haven't had that much time to devout so far and for me it's taking awhile. So many macros!

        -Lee

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

In Section Seekers of Perl Wisdom