in reply to Re (tilly) 1: What is HASH(0x17653d4) for?
in thread What is HASH(0x17653d4) for?

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.

  • Comment on Re: Re (tilly) 1: What is HASH(0x17653d4) for?

Replies are listed 'Best First'.
Re (tilly) 3: What is HASH(0x17653d4) for?
by tilly (Archbishop) on Nov 02, 2001 at 02:21 UTC
    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