I think you may be missing the point of private methods (I know I did at first).

The programmer's intent is to keep other objects/scripts from using these methods.

IMO, It is not so much about using as it is about seeing, and not so much for other scripts/object as it is for subclasses of your object. Private methods can clutter the namespace of a class, which is not usually a problem until you try to subclass it. At that point the use public/private encapsulation policies can be very useful. In C++ and some other OO languages this gets even messier when you introduce things like protected methods, virtual methods and other such insanity. But do keep in mind that these things were all invented for a good reason, and are still in use because they are very useful in certain situations, and you may just not yet encountered that situation.

I know a lot of programmers insist that you need private methods, but thats like saying 'I expect programmers using my class to be idiots'. And, well, if they're idiot, then too bad. :P

I (mostly) agree with this. The way I view it is that the "public" methods provided by a class are in essence the contract that the object provides to the outside world. I see contracts as two-way, I (as the user of the class) need to fufill my end of the contract (don't touch the private methods) in order to use your class.

However, there is a huge problem today with software reliability, and building really good, really reliable and really flexible software components is still a black art, and one that very few people/companies can really get right (and more importantly sustain, it does me no good if its not updated). Whole methodologies have sprung up that are partially an attempt to fix/address these problems (Design by Contract, Test Driven Development, etc etc etc). IMO, if you are releasing your code, anything you can do to secure it, and assure that it performs as advertised is a good thing. And keep in mind that this means breaking and die-ing in all the right places as well, that is an oft under-developed part of many modules.

Personally I just put an _ in front of my private methods and a comment tell people "This is private, use at your own risk". However, I do find the need sometimes for protected methods (ones that can only be accessed by subclasses), and for that I use this minimal Design-By-Contract inspired snippet:

sub _my_protected_method { 
    ((caller)[0]->isa(__PACKAGE__)) 
        || die "This method can only be called by a subclass";
    # ... do something 
}
[download]

This just ensures that it is only called from within its own package or a subclass of itself. And again, its not so much for the users of the class as it is for those who are subclassing. In this case, I want to provide the ability to use a method that I would not normally want in my "public" interface, and since I cannot easily "hide" it from view, I make the choice to enforce this with extreme predjudice.

To be honest, I usually don't feel that method encapsulation is a big issue. However, encapsulation of instance data is another issue (which you addressed this in your previous post). For that I use the module I created (Devel::StrictObjectHash), which works somewhat like use strict in that it really just serves to keep you from shooting your own foot off.