in reply to OO Getters/Setters

Personally, if I have to uses accessors/mutators, I use the following: 
# Assume I have foo, bar, and baz as my attributes

my $x = $self->foo;  # This retrieves the value in foo
$self->foo(123);     # This sets foo to 123 (and returns $self, to all
+ow for:
$self->foo(123)      # chaining of mutator calls
     ->bar(456);

[download]

Now, I have used generic set/get routines. We had a set() and a get(), that took attribute names. So, you would have: 

my %values;
@values{qw(foo bar baz)} = $self->get(qw(foo bar baz));
$self->set(
    foo => 123,
    bar => 456,
);

[download]

Except, there are a few issues. How do you handle misnamed attributes? What about attributes whose values are arrayrefs? It gets messy. And, it's even worse if you have a single method for doing all accessor/mutator functionality. Personally, I'd recommend against this. Maintainability will suffer.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: OO Getters/Setters
by boo_radley (Parson) on Dec 31, 2003 at 20:48 UTC 

    $self->foo(123)      # chaining of mutator calls
     ->bar(456);

    [download]
    this always gave me the heebies because returning the object for success seems a little fragile. What if ->foo() fails? Is it still sensible to return the object? What happens if you have a mutator (well, a not-mutator according to hardburn) that rejects the data presented for whatever reason? If your mutator returns an error code because ->foo(123) is bad input, you wind up with, i.e., "123 is an invalid foo"->bar(456) and your code goes pear-shaped.

    Sure, maybe "123 is an invalid foo" is up for argument as a sensible error code. The point is that it seems like a way to limit your object if you need to do any interesting things to communicate failure to back to your user.

[reply]
[d/l]
[select]
      this always gave me the heebies because returning the object for success seems a little fragile.

      I couldn't agree more, and not only is returning the object fragile, but the whole idea of an accessor and a mutator (getter and setter) rolled into one subroutine seemed to be to be just a opening for interface confusion. What if i want to provide an accessor, but not a mutator. Now convention is broken, and programmer assumptions are thrown out the window. While 'getField' and 'setField' are tedious to code initially, they have a tendency to pay off in terms of maintainability and ease of understanding for others.

      What if ->foo() fails? Is it still sensible to return the object? What happens if you have a mutator (well, anot-mutator according to hardburn) that rejects the data presented for whatever reason? If your mutator returns an error code because ->foo(123) is bad input, you wind up with, i.e., "123 is an invalid foo"->bar(456) and your code goes pear-shaped.

      I would argue here though that if '->foo()' fails, then you should throw an exception, and not return an error code. In which case the method chaining doesn't matter, since you would've longjump-ed outta there already.

      -stvn
[reply]

In Section Seekers of Perl Wisdom