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.

Sigh, why did you have to read so closely? ;)

the methods are private to that class alone and sometimes to its closest acquaintances, its immediate subclasses

My interpretion of this (though I might have to revise it) is that he means classes like Class::Singleton. The problem with "closest acquaintances, its immediate subclasses" is that you can't limit it that much. A very distant relative can override it too. Personally I don't support Class::Singleton's implementation.

Implying that I havent read perltoot? :-)

No, it was merely a thought to make the convention better known to OO programmers that are new to Perl's OO.

Oh, and im pretty sure your response falls into the "begging the question" catagory

Depending on how you read it and in what context, perhaps. I was not argumenting for or against how underscored subroutines should be interpreted. I just said that undocumented subroutines aren't a part of the interface. If you ask me that means that remote usage isn't supported. That goes for both end users and module extenders. Class::Singleton documents its underscored subroutine, and thus it indeed is a part of the interface. But as said, I don't support the way Class::Singleton was implemented.

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.

Of course public use includes subclasses and extentions. I guess you wanted to ask if private excludes usage by subclasses. It's in this disagreement were I think you and those with you are wrong--and I have my reasons. The problem occures not to the author of the derived class. The problem comes when you have modules that have a long inheritance chain, like Foo::Bar::Baz. The author of Foo::Bar::Baz has to know both Foo's and Foo::Bar's implementations. If you include modules like Class::Singleton you have even more to worry about.

When I write a subclass I would like to be able to be sure that I can write my own private routines. But as long as people will keep writing $self->_init()s and such I have to examine the code before I write my own &_init routine. That I find unreasonable!

Me: By using a function call instead of a method call he does enforce some privacy. He disables you from overriding the routine.
You: No, he renders his code difficult to extend and subclass, which I would argue minimizes the utility of his class.

No, he does indeed enforce some privacy. What that privacy renders you is another issue. But the author has effectively enforced privacy.

/.../ But its not really object oriented. Most of the code is marked as you would say "private" and uses function calls not method calls. /.../ End result is that a useful tool will stay stagnant and unextended, simply for the lack of a proper OO design

If it's not really object oriented then it of course lacks proper OO design. The Benchmark module just happens to have an OO interface/wrapper for the end user (if I read it right). I don't find that too relevant to our discussion. This says not much on how to abuse underscored methods (since the module isn't an OO module).

I'd like to draw some parallells:
* If you use the Cwd module, would you dream of redefining &Cwd::_backtick_cwd?
* Similary, if you use Pod::Find, would you dream of redefining &Pod::Find::_check_for_duplicates?
* Would you calmly override a class's &_init?
* If you build a brake enhancer to your car that relies on some perculiarities (and disables the brakes if it doens't work), would you without consideration also install it in you new car?
If you answer yes to any of the above questions you deserve a medal for bravery. You also deserve to get the medal withdrawn for stupidity. If you feel a need to override &_init then resist it and discuss a new design with the author of the module, alternatively look around for a new module. Or do as you almost did, rewrite the module to a better one.

(I consider &_init an especially good example of things that shouldn't be fiddled with. &_init is usually not called from anywhere but the constructor, and that makes it a piece of code that just as well could have been inlined in the constructor. Would you like to be able to (accidently) override inlined code too?)

Some things are meant to be private. Some things aren't meant to be fiddled with. Those things shouldn't be allowed to fiddle with, or at least not unintentionally. See this node again.

Finally, if you have D. Conways's book, then read chapter 11.1. It expresses it very well.