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.