You're advocating a workaround to allow someone to name a private method the same as a public one.

Not necessarily. It may be the other way around. The parent may add the public method after the private method was created by the subclasser. Indeed, if the parent class' author and child class' author are different persons, the latter is doing a risky task to begin with. But regardless, if someone's using the subclass and want to use this new shiny method, the naive croak()ing implementation may needlessly break code that would otherwise work.

lodin

You're advocating a workaround to allow someone to name a private method the same as a public one. That's asking for trouble.

Not at all, I am advocating that a chosen system for creating private methods should not restrict me from doing something as stupid as naming a private method after an inherited public one. After all, this is perlmonks.org and not www.bsdm-javacafe.org right? ;)

but seriously ...

private methods should not block a perfectly valid (inherited) public method from being called.

Why not?

Because, privacy (IMO) means it is only visible and relevant to the local class. So what I do in my bedroom... uhm... i mean my class, is up to me and the government ... ah,... uhm... I mean other programmers, have no right to tell me what to do.

Okay, so i am not being totally serious. But my point is that a generalized system of method privacy should be really truely private, and therefore invisible to anything outside of my class, and only applicable/relevant within my class.