Is ": lvalue" attribute usefull or something to avoid?

[TomDLux]

I'm watching Steve Baker's Perl Attributes presentation in Phoenix. He mentions the predefined attribute 'lvalue', which is an alternative to passing an assignment value as a function argument. In a package definition ....

sub value : lvalue {
   my $self = shift;
   return $self->{value}
}

....


$obj->value() = 42;

# compare with boring assignment ...

$obj->value(42)

Is lvalue useful? are people using it? or is it just a dud?

[BrowserUk]

There are two main problems with lvalue subroutines:

1. It is impossible to validate the assigned value.

   You cannot inspect the value before the assignment as it isn't accessible.

   You cannot check the value after the assignment but before returning, because the lvalue that receives the assignment must be the last thing in the subroutine before it returns.

2. The lvalue that receives the assignment must be the last thing in the subroutine.

   Even without considering the first problem above, you often would like to be able to do other things before returning.

[tobyink]

It is possible to validate the values, it's just traditionally a pain in the arse, because it involves using something like Variable::Magic or returning a tied scalar.

I wrote LV to try to get around these issues, and it does indeed make writing lvalue subs pretty friendly. The primary drawback becomes speed - none of the implementations are as fast as a more traditionally written accessor.

[BrowserUk]

It is possible to validate the values, it's just traditionally a pain in the arse, because it involves using something like Variable::Magic or returning a tied scalar.

Yes. I've done it using a tied scalars, but the penalties -- not just performance, but the obfuscation factor -- makes it a complete non-starter IMO.

none of the implementations are as fast as a more traditionally written accessor.

If the performance penalty was a few percent, the syntactic sugar might be viable; but when it is closer 200% or 300% for subroutines/methods that already have a high overhead to work-done ratio, it simply isn't worth it.

[tobyink]

Actually that sub won't work. For lvalue subs you should not use a return statement. You need something like:

sub value : lvalue {
   my $self = shift;
   $self->{value};
}

[Anonymous Monk]

Not much about it in my notes :) Re: Compact data classes, Re^2: return of hash-assigment in list context (bug?), Re: lvalue XS subs, lvalues and action at distance, Re: lhs substr(): refs vs. scalars, Re^2: Working with fixed length files

Seems, if you're parsing fixed with records with substr, use it

If you're making an object system/builder, maybe use it sometimes if you're used to c way of doing things :) ( Object::Tiny::Lvalue .... )

Otherwise don't use it

[tobyink]

Other class builders that support lvalues:

• Class::XSAccessor
• Moose via MooseX::LvalueAttribute
• Moo via MooX::LvalueAttribute
• Class::Accessor::Lvalue and Class::Accessor::Lvalue::Fast