Re: lvalue trickery solution

I think the problem is that the ~~%h you are referencing is gone (it's pad) before val is called.~~ changing new to have a new copy of %h and fixing val to end with a a reference fixes it.

update
It does fix it but not because of garbage collection. See answer in reply below.

#!/usr/bin/perl -w

use strict;
use Data::Dumper;

{
    package foo;
    use Tie::IxHash;
    use Data::Dumper;
    tie(my %h, 'Tie::IxHash', qw(one two three four));
    sub new { my %newh = %h; bless { val => \%newh } }
    sub val : lvalue  { my $r = \$_[0]->{val}{one}; $$r }
}

use Devel::Peek;
my $obj =  foo->new;
Dump( $obj->{val}->{one} );
#  dies here
$obj->val = "foo";
warn Dumper($obj);
[download]

-Lee

"To be civilized is to deny one's nature."

Comment on Re: lvalue trickery solution Download Code

Replies are listed 'Best First'.
Re: Re: lvalue trickery solution by broquaint (Abbot) on Jul 26, 2002 at 17:10 UTC
I think the problem is that the %h you are referencing is gone (it's pad) before val is called. changing new to have a new copy of %h and fixing val to end with a a reference fixes it. The `%h` is fine because it's `refcnt` never dropped below 1. But referencing the value of the hash works a treat! I can now `lvalue` assign my tied hash elements of blessed-hash object attributes to my hearts content, many many thanks shotgunefx! `_________ broquaint`	[reply]
Re: Re: Re: lvalue trickery solution by shotgunefx (Parson) on Jul 26, 2002 at 17:18 UTC
Your welcome. Chock the %newh up to cruft. Originally I thought that was the problem. Thinking it was referencing a value that was getting GC'ed. Copying %h suppressed the "Can't return a temporary from lvalue subroutine" but it just failed silently. Then I fixed val so you are correct. The temp assignment is not neccassary. -Lee "To be civilized is to deny one's nature."	[reply]