in reply to What is HASH(0x17653d4) for?

Unless an object provides a stringification operation using overload, it is guaranteed that no two references at the same time will stringify in the same way. So yes, you can use them in a hash.

However if you allocate, free, then reallocate a variable, the second one may be used where the first one was. For instance consider this code: 

sub gen_ref {
  [@_];
}

print gen_ref(), "\n";
my $keep_ref = gen_ref();
print $keep_ref, "\n";
print gen_ref(), "\n";

[download]
If you run that, you will find that the first two references that were generated at different times were named the same as each other. But when you tried to create a new one while the old one existed, Perl gave it a different name. So if the hash keys live longer than the references you are indexing into, then you may have a problem.

What is going on behind the scenes is that the name specifies the memory location where you used the data. And if Perl can it reuses the old memory location. If that is in use, then it uses a new one.

Replies are listed 'Best First'.
Re: Re (tilly) 1: What is HASH(0x17653d4) for?
by Tetramin (Sexton) on Nov 02, 2001 at 02:03 UTC
    Thanks to all the posters above.

    So a new entity gets a new string. That's all fine with me. Suppose $c = $d = new Something. Then $c and $d point to the same memory location and have the same stringification. Everything as expected. The DESTROY will delete the key if the object dies.

    Until now it sounds like I can use stringified refs to identify an object. Except for this: is it possible that the stringification changes only by time or by adding/deleting/changing data in the underlying object? The keys wouldn't reliably identify the object anymore.

    Assuming this doesn't happen wouldn't that be interesting for certain modules, like CGI.pm? $query->{name} would be $query->param('name') an keys %$query would contain nothing else but param() because extra information that is used by the module's subroutines can be outsourced to a hash with ref-strings as keys. $query would act like a normal hash reference and still be blessed to the modules subroutines. I already see myself experimenting with this alot.

[reply]
      Once the reference is assigned a location, it never moves. The data behind it may get moved, but the reference you see doesn't.

      There are only four major gotchas to using references as hash keys that I know of.

      1. It depends on stringification, so if the generator of the reference likes overloading, all bets are off.
      2. From the string representation of a reference you can't get the reference back.
      3. Names are guaranteed unique at any point in time, but not over time. As demonstrated in my code sample, it is possible for 2 references to get the same name if the second is created after the first is destroyed.
      4. If you ever make your program persistent by freezing and thawing data structures (eg with Storable or Data::Dumper) then the reconstructed references will be at new addresses.
      And yes, this fact does have some neat uses.
[reply]
        Once the reference is assigned a location, it never moves. The data behind it may get moved, but the reference you see doesn't.

        As far as I know, no part of the definition of Perl as a language, enforces this promise. The reference, as it stands, is a somewhat opaque abstraction (ie, you cannot craft or alter a reference, just its stringification).

        While it is true that currently references (well, actually objects) do not move once assigned (and this makes a lot of sense), a future implementation might very well shift objects in memory.

        This might be useful as part of an improved malloc(), that could interact with the rest of the perl internals to shift objects in memory, defragmenting the space. While this does not exist today (in Perl), I've seen systems that use a scheme like this.

        My recomendation would be to stay away from this kind of scheme. Using a reference as a uniquifying key for an object might work, but this kind of scheme, as pointed out by the previous monks, is too fragile.

        Regards.

[reply]

In Section Seekers of Perl Wisdom