But then your getters look exactly like the mutators you're trying to avoid!
Not if you don't have any mutators, they don't.
And since mutators are now deprecated, I don't see any point in letting them have the cleaner syntax.
If I were working with a group of people I needed to ween away from mutators, I might have my getters warn if @_ isn't empty.
if (@_) { carp "attempt to pass values to a getter"; }
There's another issue with my naming convention, though:
With hash-ref based objects, cheating and peeking at the hash value looks an awful lot like using the getter correctly (or course, there'd be the same problem if it were a mutator). It could be argued that this would be more visually distinct:$attribute = $self->attribute; $attribute = $self->{attribute};
$attribute = $self->get_attribute; $attribute = $self->{attribute};
Myself, I think what's needed is some sort of test code that looks for code that cheats and uses the object like a hash ref, but that's a project I keep putting off.
(And personally, I'm holding off on "inside out objects" for now. I halfway expect that in a few years Damien Conway will announce that his "Class::Std" module is now deprecated, just like a lot of stuff in his "Object Oriented Perl" is now supposed to be deprecated, e.g. mutators.)
In reply to Re^4: Method Chaining and Accessors
by doom
in thread Method Chaining and Accessors
by linenoise
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |