Re: Tied Hashes vs. Objects

[sundialsvc4]

... and I, in like manner, have had some terrible experiences with “tied hashes” that were linked to Berkeley-DB files but that were treated as hashes.   The performance was hideous:   even though a real hash would not have had these problems, it was not a real hash.   But the code that had been written to deal with them, acted as though it was.

If there is any “performance penalty” associated with the object paradigm, and with the understanding/assumption that in your case milliseconds are not in fact all that precious, then I would advocate that the object syntax “wins” because it allows you to write code that reflects what your code actually means, and to do so in only one place.   The implementation code occurs only once.

In the case mentioned above, we found that we had literally hundreds of hot-spots that had to be addressed due to, as it was, a misplaced metaphor.

[tkemmer]

I completely agree with you that tied hashes are often misused, the Berkeley-DB interface being one of the most prominent examples. However, in my case the tied hashes really _are_ hashes, i.e. the internal representation would simply be a hash reference, and just some of the accessor methods would be overwritten. I mainly posted my question because usually I shy away from using tied hashes, for exactly the same reasons you give. I think a hash is a very poor interface for anything more complex than, let's say, a hash ;-)