rename hash-key ?

[peter pilsl]

I need to rename a hashkey and wonder how to do it best.

The following seems to work:
$hash->{newname}=$hash->{oldname};
delete $hash->{oldname};

But I wonder if this could have longterm-consequences like memleaking or
something cause its a bit complicated, especially if the value itself is a
more complicated construct and I'm paranoid of failing garbage-collection
due to circular references or whatever.

---------------------------
#! /usr/bin/perl -w

use strict;

my $h={
'one'=>{0=>'ten',1=>'eleven',2=>'twelfe?'},
'two'=>{0=>'twenty',1=>'twentyone',2=>'twentytwo'},
'tree'=>{0=>'thirty',1=>'thirtyone',2=>'thirtytwo'}
};

print $h->{tree}->{1},"\n";
$h->{three}=$h->{tree};
delete $h->{tree};
print exists $h->{tree}->{1}?'yes':'no',"\n";
print $h->{three}->{1},"\n";

 

[Jeff 'japhy' Pinyan]

[posted & mailed]

I need to rename a hashkey and wonder how to do it best.

$hash->{newname}=$hash->{oldname};
delete $hash->{oldname};

delete() returns the key's value.

$hash{new_key} = delete $hash{old_key};

 

[Anno Siegel]

[posted & mailed]

I need to rename a hashkey and wonder how to do it best.

$hash->{newname}=$hash->{oldname};
delete $hash->{oldname};

delete() returns the key's value.

$hash{new_key} = delete $hash{old_key};

Note that this isn't only shorter, it's also correcter

If the old and new key happen to be the same, the original code will
delete the key after re-assigning it, leaving it missing. The one-line
version will first delete the key, then re-assign it, which amounts to
a no-op. That is (usually) what should happen in that case.

Anno

 

[Anno Siegel]

Anno Siegel ([email protected]) wrote on MMMDCCXXXIX
September MCMXCIII in <URL: > [posted & mailed]
>
> On Tue, 25 Nov 2003, peter pilsl wrote:
>
> >I need to rename a hashkey and wonder how to do it best.
> >
> >$hash->{newname}=$hash->{oldname};
> >delete $hash->{oldname};
>
> delete() returns the key's value.
>
> $hash{new_key} = delete $hash{old_key};

Note that this isn't only shorter, it's also correcter

If the old and new key happen to be the same, the original code will
delete the key after re-assigning it, leaving it missing. The one-line
version will first delete the key, then re-assign it, which amounts to
a no-op. That is (usually) what should happen in that case.


Actually, it's not always a no-op. It's not a no-op if the hash is
tied,

True. A lot of things cease to be no-ops when tied variables (or overloaded
objects) enter the picture.

and it's also not a no-op in the sense that the order in
which keys() returns the keys may change.

The order of hash keys is unpredictable. It is still unpredictable after
the operation.

Anno

 

[Rafael Garcia-Suarez]

Actually, it's not always a no-op. It's not a no-op if the hash is
tied, and it's also not a no-op in the sense that the order in
which keys() returns the keys may change.

It seems to me that the order of the keys() may change even after
a simple exists($hash{key}) with perl 5.8.2.

 

[Rafael Garcia-Suarez]

Abigail wrote in comp.lang.perl.misc :

While the order of hash keys is unpredictable, it's *documented* to
be *repeatable* if you don't modify the hash.

That's right ; my previous post was misled.