Re^3: Best Multidimensional Hash Practices?

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).

Comment on Re^3: Best Multidimensional Hash Practices? Download Code

Replies are listed 'Best First'.
Re^4: Best Multidimensional Hash Practices? by gwadej (Chaplain) on Oct 16, 2009 at 14:32 UTC
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	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: Best Multidimensional Hash Practices?
by gwadej (Chaplain) on Oct 16, 2009 at 14:32 UTC

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

[reply]
[d/l]
[select]