From perltoot:
Perl doesn't impose restrictions on who gets to use which methods. The public-versus-private distinction is by convention, not syntax. /.../ Occasionally you'll see method names beginning or ending with an underscore or two. This marking is a convention indicating that the methods are private to that class alone and sometimes to its closest acquaintances, its immediate subclasses. But this distinction is not enforced by Perl itself. It's up to the programmer to behave.
Hmm, your own quote also says that my position is not all that unusual.
It's at least mentioned in the documentation. I guess some people skip perltoot though and dig right into perlobj. Perhaps this should be mentioned in perlobj too?
Implying that I havent read perltoot? :-) Nope I did too. In fact if you have a look at my many postings youll see that I often advocate this document along with its brethren perltootc perlboot and perlobj.
But underscored methods are usually not documented and thusly isn't in the interface. They're just internal implementation.
And again the issue here is how far does "internal implementation" go? If the internal implementation is crucial to the correct functioning of the over all class then it may need to be overriden by a sub class, but still should not be used by a consumer. (Oh, and im pretty sure your response falls into the "begging the question" catagory, ie: underscored methods should not be documented because underscored methods are not documented... Ummm?)
I think it's fair to expect that undocumented methods aren't public.
Sure its fair to assume that undocumented methods arent intended for public use, but does public use include a subclass or extension to a module? I and at least a number of other programmers whose opinion I value (including it would appear from your quote above Tom Christensen) think not. You appear to think so. Horses for courses :-)
By using a function call instead of a method call he does enforce some privacy. He disables you from overriding the routine.
No, he renders his code difficult to extend and subclass, which I would argue minimizes the utility of his class. Ill give you an example based on personal experience:
I wanted to take the Benchmark module so well known and loved by all and extend it to make writing benchmarks easier and for handling a number of benchmark scenarios that are clumsy if not impossible to achieve using the current module. When I had a first cursory look over the code I saw that it was object oriented and thought that my changes should be merely overriding a routine, adding a couple of utility routines, and then done. But its not really object oriented. Most of the code is marked as you would say "private" and uses function calls not method calls. For this reason the quick extension that I had planned would have been impossible without doing the harsh trick of subroutine redifintions. So I started a complete rewrite, objectifying the module and at the same time designing it in such a way that subclassing would be trivial. Only thing is I dont have that much time, and I have a number of interests beside Benchmark. End result is that a useful tool will stay stagnant and unextended, simply for the lack of a proper OO design.
I doubt you'd recognize me.
I would if you had a name.... :-)
Yes, I haven't registered. :)
Oh come now it aint that difficult...
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.