I would antisipate some resistance to the idea from some quarters, although most, if not all of the functionality is already exposed through a collection of other modules, and is obviously available to XS programmers anyway.

I'd do it as your own module. As for a name, maybe Devel::Reference?

In other words, BrowserUk and I would both like to see a canned solution that would allow someone to stringify a reference, keep the memory around until needed, allow us to convert the string back into a reference, and release the memory when finished. This is unlikely going to be very useful to the general public, but some of the intermediate steps might be. I say 2 modules, 1 that provides all the XS basics and the second that ties them together for the specific task outlined above.

As BrowserUk mentioned elsewhere in this thread. Even the implementation I proposed doesn't mean you can't get into trouble easily.

Ok, then I offer this: here is XS code for two functions, conceal() and reveal(). (I'm not attached to the names, I just wanted a pair of names that vaguely explained their purpose.)

int
conceal(int var)
  CODE:
    SvREFCNT_inc((SV *) var);
    RETVAL = var;
  OUTPUT:
    RETVAL

SV *
reveal(char *str_or_addr)
  CODE:
    char *hex;
    int addr = (hex = rindex(str_or_addr, 'x')) ?
      strtol(++hex, NULL, 16) :
      atoi(str_or_addr);
    RETVAL = newRV((SV *) addr);
    SvREFCNT_dec((SV *) addr);
  OUTPUT:
    RETVAL
[download]

How's that? Here's a sample use of the code:

use Devel::Reference;

my $x = [1,2,3];
my $addr = Devel::Reference::conceal($x);

# the refcount of [1,2,3] is now 2

undef $x;

# the refcount of [1,2,3] is now 1

my $y = Devel::Reference::reveal($addr);

# the refcount of [1,2,3] REMAINS at 1

print "@$y\n";  # "1 2 3"
[download]

As for all that other satellite data, that could be provided, but this is the crux of the functionality. All it's really lacking right now is sanity checking, to make sure the address is recoverable when in reveal().
_____________________________________________________
Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

I don't see any reason to make two modules at all. This is not "general public" functionality.

As I've said, almost all of this functionality is already available in a mix'm'match of various existing modules. The only reason I can see for a new module would be to put all the required functionality into one place--but that's just my opinion which has just as much worth as you choose to give it:)

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

There already modules out there for helping with the task you've just outlined

?

I've never needed to use this myself but this is what I've seen other people like demerphq use when working with aliases. You could then keep @foo around somewhere and it handles the details that the values in the variables exist at some other location (without having to use another reference) and because its an alias, would handle holding weakened references just fine. That's the theory anyway. If this module doesn't do it right, this is at least the right idea. The array is implemented as a C array of pointers so all this does it make your packed list of pointers "real" instead of faked in a string.

use Lexical::Alias 'alias';

my $src;
alias $src, $foo[ ... ]
[download]