On 7/16/04 5:38 PM, David Wheeler wrote: > I've been fond of this argument myself, Dave. And I like having > separate mutators. But it's extremely common among Perl modules, and > really no different than the idea of true attributes. Using lvalue > subs, for example, one could: > > $d->day; # Accessor > $d->day = 1; # Mutator > > ...and this is how Perl 6 will behave, FWIW.
...provided you are resigned to never "upgrade" the day() to be a full-fledged method--even in a subclass--unless you are willing to jump through some hoops to retain the "$d->day = X" functionality. I find this annoying, but the P6 Cabal was not persuaded. Anyway... :) > But if you must have self-documenting methods, then maybe the Java > approach will be more meaningful and consistent for people: > > $d->get_day; > $d->set_day(1); > > After all, it's unlikely that anyone would then ever try: > > $d->get_day(1); They will if they, like Dave, are inclined to think it's "an accessor that accepts arguments to affect what it returns" ;) IMO, the get_/set_ prefixing leads to an ugly API where everything is "prefix namespaced" according to a very broad distinction of limited usefulness: "getter" or "setter". And I cringe at APIs with 50 methods that begin with set_ and 50 more that begin with get_. I have to mentally filter out the prefix noise when trying to look up methods based on the part that is the most relevant to the API (e.g. "day") It's like Hungarian notation for APIs, and Hungarian notation and Perl are an extremely poor fit for each other. (I Know, I have worked on much too much Perl code with variables like $rarhTurnips.) Anyway, Dave hates it, so I guess I should just be glad that there's a day() method at all rather than a set_day() method... ;) -John
