I'd be interested to hear your thoughts on using lvalue subs for the accessor/mutators?

Don't like them. No sir! Don't like them one bit.

For me the problem with lvalue subs is that they expose your object implementation just a little bit too much. Consider:

use strict;
use warnings;

my (%Foo, %Bar);

sub foo : lvalue { $Foo{+shift} };

sub bar {
    my $key = shift;
    $Bar{$key} = shift if @_;
    $Bar{$key};
};

foo("apples") = 12;
foo("pears") = 0;
print foo("apples"), "\n";
print foo("pears"), "\n";

bar(bananas => 3);
bar(oranges => 18);
print bar("bananas"), "\n";
print bar("oranges"), "\n";
[download]

Now, what happens if I want to prevent negative values being assigned to the hashes. With bar() it's trivial.

sub bar {
    my $key = shift;
    if (@_) {
        die "no negative numbers" if $_[0] < 0;
        $Bar{$key} = shift;
    };
    $Bar{$key};
};
[download]

With foo... it isn't trivial.

It's possible with a tied hash - but it's not simple. As soon as you need to do things with the values you are assigning (check them for validity, transform them, etc.) things suddenly get hard. You can end up with a separate tied class for each attribute.

When you get to this stage "normal" subroutines look good again - but then you're changing your API. Nasty. Best to stick with normal subroutines (be it perls all-in-one or separate setter/getter) from the start.

I really hope that perl6 takes a lesson from Eiffel and makes class attribute access and method calls look the same - that way all this nonsense can go away. Lexical subs used in this way are really just syntactic sugar for a $hash->{attr} and should be avoided most of the time (IMHO of course :-)

Updates

• s/It's/Lexical subs used in this way are/ in last sentence to remove ambiguity.
• See $foo->bar = 14; and What the [sub]in 'L value do they have? for related threads.

Agreed.

Though I would argue that the problem is not the concept of lvalue subs that is at fault, but just the current implementation.

As they stand currently, they are almost completly useless. The fact that there is no way to access the value being assigned prior to it's assignment, and that any attempt to check it after assignment prevents the assignment, is simply bewildering.

Why the value is not made available to the sub as the last value in @_ I simply don't understand. The current implementation where the assigned value magically overwrites the last available lvalue in the sub if there is one and breaks if there isn't is just simply broken.

Shame. No wonder nobody uses them.

---

Examine what is said, not who speaks.

One of my favourite languages, Pop-11, does it in quite a nice way. You define a separate subroutine for the lvalue side - known as an updater.

For example, a function to access and update the second element of a linked list can be written in Pop-11 like this:

define second(list);
        hd(tl(list))
enddefine;

define updaterof second(value, list);
        value -> hd(tl(list))
enddefine;

vars list;
[a b c d] -> list;

second(list) =>
** b

42 -> second(list);

second(list) =>
** 42

list =>
** [a 42 c d]
[download]

All the advantages of writing separate setter/getter functions without the noise (as I see it) in the function names.

In Pop-11 lvalues are poorly named, since they appear on the right! Doing value -> something in Pop-11 is the same as something = value in perl.

I find it reads well (something goes into something else) and it also solves that whole "confusing = with ==" problem.

Have a look at Attribute::Property on CPAN. It could easily be modified to use inside out objects, the current hype in Perl OO land.

My impression is that the inside out hype has abated, with Moose mania being the current trend :-)