I have often used deeply nested hashes for extracting and reordering information from logs and such. In these cases, objects tend to be overkill because there is no inherent behavior involved. The class (data container) would just be a bunch of accessors anyway.

This is actually one of the points where Perl really shines. I've done similar code in C++ and Java and the monkey motion needed to deal with classes (or structs) made the problem harder than it should have been.

In other cases, of course, using real objects is incredibly useful. But, objects aren't the cure for every problem.

You are not really sharing data among applications in that case, you are using hash, for what I consider it most useful, internalized data management with limited scope.

The problem is people who use hashes to represent complicated relationships in complicated programs. A lack of restrictions using hashes can make them a nightmare when someone can just put anything anywhere. An example of this,

my $hash{'param'} = 'lh';

# code later
$hash{'PARAM'} = $hash{'param'};

# later still
print "Param is: " . $hash{'PARAM'} . "\n";
[download]

Here an object would have(hopefully) prevented this code from showing up. Someone did not not know about $hash{'param'} but did find $hash{'PARAM'}. Or the person wrote the print statement, it did not work, so included the the second assignment rather than change their print statement(maybe multiple times).

I agree completely. I was responding to your suggestion that once objects are available, nested hashes are no longer useful.

I have had the misfortune of working on systems many times where internalized data management with limited scope was implemented using objects because everything must be an object. The resulting mess was much harder to maintain than any temporary structure would have been.

I've also been bitten by extremely complex protocols developed for the sole purpose of passing around objects that needed to be compatible across languages or versions. A simple list of hashes or hash of hashes might have been a better choice.

I'm not suggesting that hashes are better than object, they are just another tool we have available. The key is to understand the trade-offs. While I have certainly been in the situation you describe, I've also done time in other environments.

Objects don't necessarily solve the naming problem completely. What do you do with an interface that contains the methods find_object, get_object, make_object, create_object, and find_and_create_object (example anonymized from real code). At best, objects can reduce spelling errors by making them compile errors. But, making a badly-designed hash into a badly-designed object isn't really an improvement.

Until I tried to explain this, I hadn't really thought of using hashes on simple problems to help teach object design. It's sometimes easier to focus when the rest of the mechanics isn't in a student's way.

G. Wade