One of my projects allows customization via small (presumably) bits of Perl code embedded in a definition (something that isn't XML but soon will be). These are functions for (say) formatting a data element or calculating a field when a record is retrieved. They are written by responsible parties (either my co-workers or knowledgable folks at customer sites) so I don't need to worry about the actions taken by the code.

My code checks a definition to see if it has one of these snippets, and replaces the snippet with a code reference to a compiled function the first time it is used. A given application definition might contain a large number of these small functions, and chances are good there will be duplicates, so I wanted to gain further efficiency by caching the compiled versions and sharing the cache among all the object definitions.

The first thing that came to mind was to construct a hash keyed on an MD5 hash of the function. But as I was starting to put that together, I wondered if a plain hash wouldn't be just as simple and easy. That is, given a bit of Perl in $code, store it like:

$function_cache{$code} = eval "sub {$code}";
if ($@) { # handle bad code errors... }
[download]

Given that Perl is going use its own hash function on the text of the code to construct the internal key value, this seemed equivalent to the MD5 version and probably faster. I would have stored the text of the code somewhere anyway for debugging purposes; the fact that a regular hash does this for me is just gravy.

Am I doing anything terrible to Perl in using a hash with longer than usual keys? Any suggestions on better approaches?