At 11:11 PM 11/3/01, Gerald Richter wrote: > > > > > Methods and Functions (except for special cases, like AUTOLOAD) begin > > > with a verb, with words following to complete the action. > > > > I'm not sure I agree with that 'must begin with a verb' bit. For simple > > accessors, I don't see much value in $foo->get_story over $foo->story, > > particularly, if you want to combine your get and set methods for > > attributes into one. > > > >One argument for using $foo->story as get _and_ set method, instead of >get_story and set_story, is that it is used this way by mod_perl (1.x & >2.x). Also I think one method for get/set is very common to Perl and >get_/set_ comes out of C++ and Java.
My main point: I haven't followed the thread closely, so forgive me if this was mentioned before but the thing that is crucial about get and set as a prefix is if you wish to support Bean-like conventions. The debate is still out on whether beans is a good thing to support in Perl, but I did list some benefits (from a Java perspective) earlier in this mailing list. Some ancillary points for those that care to read on about more minor complaints: On a gut level, I really dislike methods or functions whose purpose in life is to both mutate data and access data based on passed parameters. It just feels "wrong" to me and that is even before I was so involved in Java. "Wrong" because to me a method or function should be orthogonal to its name and do one basic action. Mutate and access functions are two different actions. I can understand that someone could argue that they are doing the same thing because the operate on the same attribute, but cognitively I view one of those actions as being quite passive and the other quite active, so I guess I feel that they are different. Taking the argument further, there are a lot of methods that might act on a single attribute of the object, but that doesn't mean they should be shoved into one method whose name is the attribute... By the argument that any action that affects a single attribute should be a single method, we might get the following scenario: a car object with a speed attribute. Instead of having a method to speed up the car (press on the gas peddle) and slow the car (press on the brake), you would have $car->speed(); # get the speed $car->speed(60); # set the speed) $car->speed(10, 'slowdown'); # now overload to slow down the speed $car->speed(10, 'speedup'); # now overload to increase the speed etc... I guess I just feel that the idiomatic approach promotes non-intuitive programming practice at the expense of not really saving that much typing. On the other hand, I can understand why Perl guys wouldn't care. In strong typed languages, one big advantage is that many properties should not be settable, and this can be accomplished or checked at runtime by making sure that the setXXX method is not defined (or is private to that class) so that the public cannot set anything and therefore break the interface. However, I don't think this is entirely it. Because Java could have void speed(float) and float speed(); methods. This is perfectly legal and would still satisfy it's strong typing. Of course, it looks a bit ugly to most Java programmers because most overloaded methods still return the same type, but overloading but returning different types is perfectly legal as long as the signature of the parameters are still different. So I suspect it goes deeper than that as to why the Java folks stick to the convention of using verbs. It's not just because of a language feature that Perl has that Java lacks. It really is a convention. I tend to like conventions that don't have exceptions. The more exceptions, the more annoying life is.
