And... sure. It works. But the whole approach makes me want to disavow it. The right "value" should be a simple list (or sub-hash? seems unnecessary) containing both values. But using a "two strings smacked together" key just seems wrong. I'm just not sure what would ACTUALLY be simpler (for values of 'simpler' approximating "easier for a programmer to understand.")
Well, an in-memory database would be nicest, if there is an easy way to query it. And to be fast, it would build two indexes, which would either be b-trees or... *drummroll* hash tables.
But I wouldn't introduce such a big dependency for a relatively trivial feature.
So in the end I think it boils down to two hashes, which is the most pragmatic solution in Perl space.
It works, it isn't very complicated, it's easy to udnerstand for the reader -- what more do you want? Unless memory becomes scarce, I'd stay with the current solution.
In reply to Re: A question of style: Composite keys to multiple values
by moritz
in thread A question of style: Composite keys to multiple values
by Voronich
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |