sub mk { join '', sort @_ }
$hash{ mk 'a', 'b' } = 'Some Value';
print $hash{ mk qw{ b a } };
It's still a little bit of extra typing, I'll admit. It doesn't involve modifying how the hash code works, though. I don't think having a few extra characters obfuscates the hash usage at all.
You might also notice that by joining with an empty string, you're able to use arrays as well as lists. That's one of the benefits of Hash::MultiKey over standard Perl multi-keyed hashes, but without the tie.
Another advantage is that in many cases you can do the sort and join once, saving the result into a simple scalar for later use. It may be frowned upon as a premature optimization, but it could help the clarity of the code over a tied hash.
In your example, I'm not quite certain why you'd be storing the results of two tests as one entry in the hash in the first place. Are you specifically testing pairs of mutually dependent items?
if ( $tests{ $refA } && $tests{ $refB } ) {
# This checks two hash entries very cleanly, but falls down
# if the results are dependent on whether A and B are tested together
+.
# some stuff
}
With something like Hash::MultiKey, I'm not sure from the top of my head when I'd use the fact that each() and keys() return an arrayref of strings instead of the concatenated string, but surely someone's found a use for that feature because it's all over the examples. If I thought of a solid reason I'd want that, then using a module which does that would probably be worthwhile.
I'm not trying to discourage you from publishing your module; I'm just giving you the feedback you requested. I, personally, probably won't use your module. If you find your module useful enough to put it on CPAN, other people will probably find it useful enough to download from CPAN. |