in reply to Experimenting with Lvalue Subs

You missed one part of the trick. The body of an lvalue sub doesn't get executed when it is used as an lvalue. The trick works only if the last expression is an lvalue (as is trinary op). That means you do no good to shift in or copy the function arguments. $key and $self in your example are undefined when called as an lvalue.

Arguments are still usable, but you need to initialize them in the last line of the sub. Here's a minimal rewrite.

sub get_set :lvalue { my $junk; key_ok( $_[1] ) ? $_[0]->{ $_[1] } : $junk; }
Note that $junk is effectively a package global variable holding the last value assigned with a not-ok $key. You can retrieve it with $foo->get_set($bad_key), but the value returned is for any $foo of the class.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re^2: Experimenting with Lvalue Subs
by Limbic~Region (Chancellor) on Jan 24, 2005 at 18:59 UTC
    Zaxo,
    The body of an lvalue sub doesn't get executed when it is used as an lvalue.

    Not sure if that was the original behavior back in 1999 when they were first introduced but newer versions certainly disagree with you:

    my %foo; get_set( 'foo' ) = 42; print get_set( 'foo' ); sub get_set :lvalue { my $key = shift; print "key is $key\n"; my $junk; $key eq 'foo' ? $foo{$key} : $junk; } __END__ key is foo key is foo 42
    ...You can retrieve it with $foo->get_set($bad_key)

    Where $bad_key is any and all bad keys. This is why one of the desired features would be to determine if it was in assignment or not.

    Cheers - L~R

      Now _that_ is interesting. Anybody know when it was introduced?

      /me is off to experiment anew . . .

      After Compline,
      Zaxo