My preference is definately for the

$employee->salary($employee->salary()*1.1);
[download]

form. Partly, this is laziness, but mostly because I haven't seen a clear argument as to the benefits of the get/put form.

Ideally, where the attribute is a numeric one, I'd like to be able to do

$employee->salary() *= 1.1;
[download]

This can be acheived with use overload (I think), but it would require a fair amount of effort to overload all the appropriate operators.

Easier than this is to make the accessor methods, lvalue subs. This removes the need for overload.pm in many cases and greatly simplifies the code. The unfortunate downside of this is that there is no way to apply restrictions or validations to the values set into the object. This works well enough for some types of modules, such as those used only as glorified aggregate datastructures, or where it is acceptable to place the onus of only supplying 'good' values on the users of the module. So called 'unenforced contract interface design', which is quite perlish in its philosophy of recommending you stay out of the barn, but not backing it up with a shotgun:)

#! perl -slw
use strict;
package Test;

my %numbers;
sub new{
    my $self = bless \rand, shift;
    $numbers{$self} = 0;
    return $self;
}
sub number :lvalue { $numbers{+shift}; }

package main;

my $number = Test->new;
$number = 3;
print $number;
$number *= 1.5;
print $number;

__END__
3
4.5
[download]

Of course, there will be many situations where the lack of enforcement will not be acceptable to the project design, but that is often a judgement call rather an a pre-requisite. A more serious limitation is that if the representation of the attribute changes in a way that means that using lvalue accessors is no longer feasible, then it becomes extremely difficult, if not impossible, to modify the class in such a way as makes the modification transparent to calling code.

I've had various attempts at finding a workaround for this limitation of lvalue methods, but haven't found anything satisfactory. I also held out hope that Perl6 might provide a solution, but my reading of Apocolypse 6 recently scuppered those. LW seemed to fairly clearly dismiss the idea--with impecably argued reasoning--but I still find myself hankering for a way of having lvalue subs that could validate their assigned value either before or after assignment.