The bottom line is, if you want to use object oriented programming, you're better off using a language designed by someone who understood the concepts of object orientness. And not a language that found a cute trick to use arrows.

I think that's a tad harsh :-)

Most of the perl I write is OO. I have to take more care in some areas than I would in certain other languages, but it's still a win in terms of easy of production & maintainence than the equivalent non-OO perl.

It's also a win over writing it in C++/Java/Eiffel/whatever because perl gives me other advantages in producing functional working projects in a timely manner.

I'm not saying good encapsulation is not important - it is. But it's not the only advantage that OO gives you. I'm not even sure it's the most important one.

Typos in hash keys can cause bugs, but they're simple bugs that are easy to track down and fix.

Leading "_" characters to indicate "private" hash keys and method names are potentially more dangerous. Especially since they're normally excused with the line:

"Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun."

Which, while a colourful statement, hides the fact that the problem isn't forced entry, it's accidental trespass.

That said, I've only encountered problems relating to these issues a couple of times in several years of (pretty complex) OO perl. It's rare you get deep inheritance, rarer still you encounter a name clash.

I'm not saying it isn't a problem. It is. It can lead to some evil bugs that are hard to track down. One of the many reasons I'm looking forward to perl6 is that it's likely to clean up this mess. I'm just saying that it's not necessarily a common problem in many real world situations.

There are, of course, many ways around these issues:

• Your very own inside out objects (a lovely hack) cuts around the whole issue nicely. It also allows you to inherit from an evil hash object if necessary.
• Call private subs as functions rather than methods to stop sub-classes accidentally overriding them.
• Implement private subs as lexically scoped code references if you're really scared about people playing with them :-)
• Use Class::Delegation to wrap classes that cause inheritence problems.
• ... and so on ...

However, I would question whether these ideas can be usefully be introduced into a tutorial aimed at novices.

Hashes may not be ideal, but they're fairly simple to teach - and are familiar to perl coders from elsewhere. The kind of problems they introduce are not likely (in my opinion) to be much of a problem to the novice. Once you stop being a novice there are other techniques available that can solve the problems.