http://www.perlmonks.org?node_id=486272


in reply to Re: Things I Don't Use in Perl
in thread Things I Don't Use in Perl

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. 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. 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? 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? Wantarray will be defined, so you have no way of reliably knowing if you were really called as get or set.

It is more readable, safer, and simpler to code:

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}; }
<-radiant.matrix->
Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
The Code that can be seen is not the true Code
"In any sufficiently large group of people, most are idiots" - Kaa's Law

Replies are listed 'Best First'.
Re^3: Things I Don't Use in Perl
by demerphq (Chancellor) on Aug 24, 2005 at 16:59 UTC

    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:

    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)

    has an interesting property given the example before:

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

    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 @_;

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

    ---
    $world=~s/war/peace/g

      Interesting points. To be fair, the original implementation only sets the name attribute equal to $_[0] as well, by virtue of $self->{name} = shift. I was less interested in the case of empty array as I was in the case of setting the attribute 'name' to be a scalar value, which seemed to make more sense. Should have been more clear. ;-)

      As to die "No arguments in set_name()" unless @_;, note that I did leave a space in the setter to validate behavior, since we aren't going from a spec. Depending on the behavior required, that line may or may not be appropriate. The behavior you described as erratic is what I intended, but its interesting that we looked at the same OP and drew differing conclusions.

      I guess this is an example to designers about how unclear specs can lead to unexpected behavior. ;-)

      <-radiant.matrix->
      Larry Wall is Yoda: there is no try{} (ok, except in Perl6; way to ruin a joke, Larry! ;P)
      The Code that can be seen is not the true Code
      "In any sufficiently large group of people, most are idiots" - Kaa's Law