Re (tilly) 3: What is HASH(0x17653d4) for?

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.

It depends on stringification, so if the generator of the reference likes overloading, all bets are off.
From the string representation of a reference you can't get the reference back.
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.
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.

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

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

Replies are listed 'Best First'.

Re: Re (tilly) 3: What is HASH(0x17653d4) for?
by fokat (Deacon) on Nov 02, 2001 at 03:16 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.

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]