1. Return the previous value (or undef if none). Rationale: Saves performing a 'get' prior to the 'set' in case you need to restore the previous value.
2. Return the value being set. Rationale: Allows you to check that it got set correctly.
3. Return the object itself. Rationale: Allows you to chain methods together: $obj->set_xxx($value)->do_something_else()

I know in the Java world there are distinct getters and setters and they seem to follow a fourth path that you didn't list where setters are void and getters return the value.

In writing objects in Perl I've always followed the pattern of having the getter and setter be the same routing where I test for a passed in value and if it exists I set the member field to that value. No matter what if there was a passed value or not I still return the value contained in that member field. In the case of where a value was passed in I return the newly set value.

#
# Getter Setter for member field foo
sub foo {
    my $self = shift; 
    if ( defined $_[0] ) {
      $self->{foo} = $_[0];
    }
    return $self->{foo};
}
[download]

Which is the best way? I think your milage varies and it all depends on personal preference or the architecture you are building against.

---