OK, everybody is going to give you different answers, from "you can't do that" to "you shouldn't do that"... I'll try to explain the "why"

Perl has, per se, non concept of "private" methods: a package is a name space: it contains names for things (subroutines, but also variables, etc). OOP in Perl is based on the fact that, by blessing a reference, you attach to it the name of a package. Then, when you use it with the "arrow notation", Perl looks at the name of the package you have attached to the reference, and starts from it to look for a subroutine with the name you specified (I assume you know how the inheritance works). At no point Perl consults some attribute of the reference, the packages, or the subroutines, to discover if it was OK for you to call that subroutine.

This is a design choice. Maybe not the best one (Perl6 will have proper privacy of members), but the one that has been made. The idea was that it was both easier and more flexible to do it this way, and that the programmers would just avoid to step on each other's toes.

There are several modules out there that muck with the inheritance, add methods to other classes, and generally behave pretty poorly if you judge them "by the book". But the main goal, in Perl, is to get the job done. If you need strong encapsulation and privacy, there are modules that can give them to you (you'll get plenty of pointers from other people, I'm feeling a bit lazy at the moment); and the reason that you can get them is that Perl does not provide them itself, but instead leaves everything wide open for anybody to tinker with.

Oh, as a sidenote, Perl6 will both have privacy and encapsulation, and permit to tinker with classes at will. It will just be a little better presented ;-)

-- 
        dakkar - Mobilis in mobile