Re: Tied Hashes vs. Objects

If you need case-insensitive keys, just lc() the name and store the unaltered name as part of the value (which is itself a hash). An object wrapper for all of this is generally a fine idea because it encapsulates all of the gory details into one module so they won’t spread. Why give any second thought to “performance?” Next year’s hardware will always be faster. (This is not a performance-critical edge case.) If the software is unmaintainable over the course of several years, it will be counted vastly more expensive than the “iron.”

Replies are listed 'Best First'.
Re^2: Tied Hashes vs. Objects by Anonymous Monk on Oct 22, 2012 at 18:35 UTC
Dear fellow monk, thanks for your advice. Rest assured, the actual implementation of these "special" hashes (case-insensitive keys, read-only hashes, substring keys, whatever they come up with) is of little concern here, and can -- and has actually mostly been -- dealed with. The issue about performance came up, because, well, these operations may be called A LOT. So if there is any significant difference betweeen tied hashes (which map hash operators to OO-style methods, basically) and calling these methods directly, I would really like to know.	[reply]

Replies are listed 'Best First'.

Re^2: Tied Hashes vs. Objects
by Anonymous Monk on Oct 22, 2012 at 18:35 UTC

Dear fellow monk, thanks for your advice. Rest assured, the actual implementation of these "special" hashes (case-insensitive keys, read-only hashes, substring keys, whatever they come up with) is of little concern here, and can -- and has actually mostly been -- dealed with. The issue about performance came up, because, well, these operations may be called A LOT. So if there is any significant difference betweeen tied hashes (which map hash operators to OO-style methods, basically) and calling these methods directly, I would really like to know.

[reply]