Advertisement
Reading Conway's 'Perl Best Practices' lately, and I've been debating with myself over his tip on accessors on page 340:
"Provide separate read and write accessors."
I have always gone the (fairly) typical route of writing a single and aptly-named accessor for each object attribute. Though I can't argue w/ Conway's points on the matter, I'm having a hard time thinking that the single accessor method creates a nicer interface to the object.
What do y'all have to say about this one?
"Provide separate read and write accessors."
I have always gone the (fairly) typical route of writing a single and aptly-named accessor for each object attribute. Though I can't argue w/ Conway's points on the matter, I'm having a hard time thinking that the single accessor method creates a nicer interface to the object.
What do y'all have to say about this one?
posted by:
|
Unsubscribed |
Advertisement
Advertisement
-
Unsu...
Re: Provide separate read and write accessors.
Mon, October 31, 2005 - 3:25 AMgetFoo() and setFoo($bar) are pretty commonplace in OO world beyond Perl. Personally, I too appreciate the "do only what it says" philosophy for naming methods, and I feel that overloading a single routine kinda gets messy.
For me single read/write accessors are not a nicer interface, so much as a smaller interface. IMHO, A nice interface is one that follows a logical naming convention and whose methods don't try to do too much-- even if it means 20 accessors instead of 5.
To get to the point, I guess I have to go with Conway on that one.
Just my opinion, of course. Currently on sale for $.01. ;) -
-
Unsu...
Re: Provide separate read and write accessors.
Mon, October 31, 2005 - 6:20 AMMy argument against boils down to the fact that Perl objects lack attributes, and that the single r/w accessors allow us to simulate them. If I'm working in Python, I can have an attribute w/out writing a method to deal with it, and I have the option of saying:
myobj.attr = 'foo'
print myobj.attr
Of course, we can take the simulated attributes a step further using :lvalue, but that's supposed to be bad, too. -
-
Unsu...
Re: Provide separate read and write accessors.
Mon, October 31, 2005 - 7:01 AMI think Conway's angle comes with keeping Perl object-oriented, or at least that's what I am assuming since he wrote the defacto textbook on OOPerl.
Using attributes the way you suggest, although handy, sorta negates the "black box object" philosophy which drives OO modularity. The whole sticking-to-proper OO perl thing really comes in handy when you are programming in a team. Since Perl doesn't have any method/class modifiers to enforce what props/methods it shows/doesn't show, a programmer has even more of a responsibility to pick a design methodology and stick to it, so as to not confuse anyone else who has to use the object later.
In the end, I think it boils down to different strokes for different folks (and different projects). I wonder if Conway is trying to drive home the idea that "best practices" are OOPerl practices (which is something I don't necessarily agree with 100%)?
Again, just my opinion, but hey, you asked. ;) -
-
Re: Provide separate read and write accessors.
Tue, November 1, 2005 - 5:50 AMOnce again, I really need to get this book.
I usually stick to the standard perl methods cget and configure and implement them in my objects.
-
Re: Provide separate read and write accessors.
Mon, November 14, 2005 - 4:02 PMI have to go with Mssrs. Conway and Schwartz on this one, for a whole host of reasons.
it's not really an OO thing at all: I think having a single getter/setter method is really something that's *only* done in Perl (my impression is that Python people know better), because most languages don't allow it or make it awkward--to take the Prime Procedural Language, how many functions in C act as both setters and getters? how clear would your C program be if all your data functions acted like ioctl(2)?
IMO it's an abuse of Perl's flexibility that hinders readability. -
-
Unsu...
Re: Provide separate read and write accessors.
Mon, November 14, 2005 - 5:00 PM>IMO it's an abuse of Perl's flexibility that hinders readability.
Agreed. Hence my earlier statement on being responsible and sticking to a design methodology, no matter what it is. Perl's flexibility will allow you to easily diverge from it if you aren't careful.
-
-
-
-
-
Re: Provide separate read and write accessors.
Sun, November 13, 2005 - 2:25 AMIn our classes, we teach that there are two schools of thought. The biggest problem with having getters also be setters boils down to misunderstanding a read-only attribute. People have been burned by typing
$some_object->read_only_thingy($newvalue);
thinking it will set a new value. Yes, there should have been error checking, but there often isn't.
Also, having differently named getters and setters makes it easier to grep through the source code to look for setters (very important) and for coverage testing to make sure you've called set rather than just get.
