sub FETCH {
  my($s, $k) = (shift, shift);
  return exists( $s->[0]{$k} ) ? $s->[2][ $s->[0]{$k} ] : undef;  
}
[download]

Suggested and untested solution: $h {one} = undef after the tie.

Abigail

You haven't stored anything in the hash yet, so $_[0]->{val}->{one} returns undef, which isn't an lvalue.

Erm ...

{
    package foo;
    use Tie::IxHash;
    tie(my %h, 'Tie::IxHash', qw(one two three four));

    sub new { bless { val => \%h } }
    sub val : lvalue  { $_[0]->{val}->{one} }
}
use Data::Dumper;
my $obj =  foo->new;
print Dumper( $obj );

__output__

$VAR1 = bless( {
                 'val' => {
                            'one' => 'two',
                            'three' => 'four'
                          }
               }, 'foo' );
[download]

I figured that the issue might be in the FETCH method of Tie::IxHash, but I thought that tied variables were meant to behave just like normal variables (in terms of interface at least), apparently not.

_________
broquaint

#!/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]

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

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."

Maybe that's the bug? It might be an auto-vivification issue, more than a tie issue.

That's a wild guess, though.
--
Mike

Hmmm, in the "untied" branch, you assign to $obj->val before the dump; you do it after in the version that dies.

Well I can't do the Dump after the $obj->val assigment as that's where it dies. I don't believe it's an auto-vivification issue as there's nothing that's being auto-vivfied and if you Data::Dumper the object you can see that both tied and untied are exactly the same.
HTH

_________
broquaint

Well I can't do the Dump after the $obj->val assigment as that's where it dies.

oh yes, you can:

$SIG{__DIE__} = sub {
    Dump( $obj->{val}->{one} );
    die $_[0];
};

{
    package foo;
    use Tie::IxHash;
    tie(my %h, 'Tie::IxHash', qw(one two three four));

    sub new { bless { val => \%h } }
    sub val : lvalue  { $_[0]->{val}->{one} }
}
use Devel::Peek;
my $obj =  foo->new;
#  dies here
$obj->val = "foo";
[download]

still, this doesn't solve anything :-)

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
[download]

Ah, missed that. I thought the "many more lines of 0's" on the dump was where it was crashing.

Do you have the same problem if you use another Tie module?
--
Mike

    sub val : lvalue  { $_[0]->{val}->{one} }
[download]

sub val : lvalue  
{ 
  $_[0]->{val}->{one} = undef unless exists $_[0]->{val}->{one};
  $_[0]->{val}->{one};
}
[download]