Using stringified refs for unique IDs?

Masem has asked for the wisdom of the Perl Monks concerning the following question:

In this node, I ask about a way to catch variables as they go out of scope as to avoid reference caching (update NOT catching) in a Factory-like class. While weak references was suggested as one possible solution, this only works in 5.6, as weak references weren't possible without patching 5.005. I'd like to keep a solution that works in 5.005 as well.

Another suggestion, as given by chip in this node was to use unique IDs that are stored in a package level hash, such that the Factory class stores only these IDs, which does not appear to increase the reference count to the object, such that they can be deleted when they go out of scope. The only problem with this, potentially, is that the counter that acts like a unique ID could roll over, but realistically I would not expect that to happen.

However, thinking about this and any other way to generate a sufficientl unique ID, I though about stringifying the references as a unique ID, that is, instead of this code that chip offered:

$TEMPS{ $self->{ID} = ++$TEMPID } = $self;
[download]

I would use:

$TEMPS{ $self->{ID} = "$self" } = $self;
[download]

Is there any serious problems with this? As opposed to the int case, these will stop to resolve right once your memory is full, which problems would be expected to happen anyway. I'm pretty sure that references would remain fixed in memory once created, but I can't see any other caveats. Any concerns about this?

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Comment on Using stringified refs for unique IDs? Select or Download Code

Replies are listed 'Best First'.
Re: Using stringified refs for unique IDs? by perrin (Chancellor) on Nov 14, 2001 at 12:14 UTC
Memory locations (which is what the stringified reference reveals) are okay as long as you only care about them being unique for one run of one program in one process. For anything else, stay away. For example, I've seen people use memory locations as random session IDs for web code, which is not safe, especially in a cluster. Personally, I don't think it's such a good idea to replace clean code that works (from chip) with code that is confusing for newbies and might not work if something changes about Perl's memory allocation scheme.	[reply]
Re: Using stringified refs for unique IDs? by dws (Chancellor) on Nov 14, 2001 at 11:10 UTC
I assume this is backed up by `sub DESTROY { my $self = shift; delete $TEMPS{"$self"}; }` [download] As long as you're not overloading "" in some evil way, this should work fine.	[reply] [d/l]
(jeffa) Re: Using stringified refs for unique IDs? by jeffa (Bishop) on Nov 14, 2001 at 10:49 UTC
First off, chip++ for that code. I had always heard that you can't use references as keys, but nobody said you can't use the string that represents the reference as a key. So, for a naive test, i tried this: `use strict; my %TEMPS; my $max = 1_000_000; Foo->new() for (0..$max - 1); print "ok\n" if $max == scalar keys %TEMPS; package Foo; sub new { my $self = {}; $TEMPS{ $self->{ID} = "$self" } = $self; return $self; }` [download] My reasoning was that if the number of objects i created equals the number of keys in the hash that contains them, no duplicate id's were used. The result was "ok" ... jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR F--F--F--F--F--F--F--F-- (the triplet paradiddle)	[reply] [d/l]