in reply to Re: Re: How to change referent of lexical reference?
in thread How to change referent of lexical reference?

Sorry about that, though if your original question had been stated as clearly as here, then it might have saved a few false impressions:)

The best suggestion I can make is that you keep a hash, with frozen copies of the in-memory datastructures that might match as the keys, and a reference to them as the values.

When you import a frozen datastructure, you then just look it up in the hash and if you find a match, set the pointer to the new one to the value from the hash, and there would be no need (or point) in asking Storable to thaw the inbound structure. If not, just thaw() as normal.

This would mean maintaining the frozen copies as the get modified, but this could be easily done by tieing the structures that make up each compound structure, and updating the frozen copy, cash hash on STORE.

This arrangment would make for fast isolation of matching structures at the expense of the overhead of re-freezing when elements of the structure are updated.

If you really wanted to trim that overhead, you could start playing games with arrays of lvalue refs into the frozen copy and overwrite individual fields, packing the data yourself, but this would require some effort to set up for the general case and you'll probably consider that overkill.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.
  • Comment on Re: Re: Re: How to change referent of lexical reference?

Replies are listed 'Best First'.
Re: Re: Re: Re: How to change referent of lexical reference?
by autarch (Hermit) on Sep 23, 2003 at 04:39 UTC
    The whole point of doing this is so that people who use this module can freeze and thaw objects and not know what weirdness is going on in the background.
[reply]

      What can I say. Storable does not, and could not1 provide the facility you are asking for, so I offered you a possible solution.

      1 What you are asking for would require Storable to scan the entire in-memory image of your running application locating all global, localised and my'd (pad) storage areas looking for structures that resemble that being thawed(). Not only would this be extremely difficult, if not impossible, it would also be extremely slow and ultimately unreliable as you could never be sure that the calling program would be aware that it was holding two pointers to the same data, or even that the two pointers were originally pointing to the same data. This would lead to the situation of the caller modifying one object and inadvertantly altering another without realising it.

      However, if all the datastructures are (or were made) objects of the same class (or of derived classes), then you could wrap that around Storable, tie the structures and use the additional knowledge you would have of the implementation to set up cache hash as I described.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
      If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]
        I never suggested Storable should provide this. All I wanted was a way to do what I wanted in my code when STORABLE_thaw() was called. And I found it. It simply meant swapping the reference at the C level rather than the Perl level, because Storable is calling STORABLE_thaw() from C.
[reply]

In Section Seekers of Perl Wisdom