in reply to Single accessor/mutator idiom in Perl5, Perl6 and Python

I personally like my mutators/accessors made in such a way, that if you are setting a value, it will return the old value. Something like: 
sub foo {
    my $self = shift;
    my $old = $self->{'foo'};
    $self->{'foo'} = shift if @_;
    $old;
} #foo

[download]
It makes the accessor/mutator more flexible at the expense of a little overhead. If you're worried about the overhead, you should probably access the hash keys directly ;-)

And of course, many of these accessor/mutator methods are created automatically when they are needed using some AUTOLOAD magic.

Liz

Replies are listed 'Best First'.
•Re: Re: Single accessor/mutator idiom in Perl5, Perl6 and Python
by merlyn (Sage) on Aug 17, 2003 at 16:27 UTC
    In the alpaca book, I argue that a setter might return one of many possible values:
    • The value just being set
    • A success/failure boolean
    • The previous value
    • The value of $self (for chaining)
    All have merit, and choosing any one means you don't get the others. Please don't have a religious war here. {grin}

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
Re: Re: Single accessor/mutator idiom in Perl5, Perl6 and Python
by demerphq (Chancellor) on Aug 17, 2003 at 10:55 UTC

    I personally like my mutators/accessors made in such a way, that if you are setting a value, it will return the old value.

    I find that this approach is a little strange. It makes sense for a subroutine like select or delete but for a get/set accessor I think the behaviour would be a touch unusual. A set accessor is like an assignment statement, and as such I would expect it to behave similarly to an assignment operator.

    Although I admit that often I use the "return $self on set" approach quote a bite as I like the economy of notation that this provides the end user.

    And of course, many of these accessor/mutator methods are created automatically when they are needed using some AUTOLOAD magic.

    Ive done this as well, but apparently its use should be carefully considered as each time AUTOLOAD creates a new method the method cache is spoiled for _all_ methods, meaning that there could be considerable performance hit from doing it. I've not experimented to see how critical this is, but more than one knowledgable monk has made this assertion and I have little reason to doubt them.


    ---
    demerphq

    <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
[reply]
[d/l]
[select]
      ...I find that this approach is a little strange. It makes sense for a subroutine like select or delete but for a get/set accessor I think the behaviour would be a touch unusual...

      I must say, I don't need it much. But when I do need it, I don't have to think about it. And it's not getting in the way of anything otherwise.

      ...the method cache is spoiled for _all_ methods, meaning that there could be considerable performance hit from doing it..

      Surely that is negligeble if you're calling the same method many times? And if you're not, your program probably doesn't run long. So you won't notice any performance hit.

      Not creating a subroutine and keeping it part of the AUTOLOAD routine,. will mean a lot of lookups will have to be done for each method call. Which is certainly a performance hit.

      I guess YMMV ;-)

      Liz

[reply]
Re^2: Single accessor/mutator idiom in Perl5, Perl6 and Python
by adrianh (Chancellor) on Aug 17, 2003 at 15:57 UTC
    I personally like my mutators/accessors made in such a way, that if you are setting a value, it will return the old value.

    I do that sometimes if I think it would be useful. I usually return $self so $i->can->chain->methods->like->this - but I probably shouldn't start that discussion again :-)

[reply]
[d/l]
[select]

In Section Meditations