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

In reply to Re: Re:(4): •Re: Upgrade B::Deparse? by diotalevi
in thread Upgrade B::Deparse? by Hrunting

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.