As implemented, your example would fail if the called in scalar context, as in $name = $object->name;, because wantarray will return false if you've called in scalar context.

Good catch.

To check for void context, you need to check if the result of wantarray is undefined. This illustrates how easy it is to make a mistake with single get/set methods.

Personally I feel this is a better illustration of how it is unwise to post untested code when you haven't even finished your morning cofee. Of course I'm biased. :-)

Also, what if it is valid to set the name property to an empty string, the string '0' or undef? How would you do that with this combined get/set?

With the bug you noticed squished the code presented does all of that doesn't it? If $obj->name(0) is called then it $obj->{name} gets set to 0, likewise with undef. The case of interest is when its called with an empty list.

Oh, you could play with wantarray to find out if you're getting, but what if (as is the case in the original, and common) the set method is to return the value set?

Here it is again slightly modified to match your code:

use Carp;
sub name {
  my $self = shift;
  if (@_) {
    $self->{name} = shift;     
  } elsif (!defined wantarray) {
    croak "Error:",
          (caller(0))[3],
          " called in void context with no arguments";
  }
  return $self->{name};
}
[download]

So if we call it with arguments it either returns the old value, or returns self, whichever flavour you like. In fact your code (which is below)

sub set_name { 
    my $self = shift; 
    ## validation /untainting here ##
    $self->{name} = shift;
    return $self->{name};
}

sub name     { 
    my $self = shift; 
    if (@_) { warn "Attempt to set value in get" }
    return $self->{name};
}
[download]

has an interesting property given the example before:

my $val = $obj->set_name(@foo);
[download]

If @foo contains something then $val and $obj->{name} ends up equal with $foo[0]. But if @foo is empty $val and $obj->{name} go to undef. Thus $obj->set_name() is equivelent to $obj->set_name(undef), but with the combined setter, $obj->name() returns the original value of the field, unless its in void context where it is an error. To me its quite arguable which of these two behaviours is to be preferred, and i might even go so far as to suggest that the posted implementation of set_name() should have something like

die "No arguments in set_name()" unless @_;
[download]

and possibly use it as a way of illustrating how easy it is to make a mistake in a split get/setter. :-)