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... }
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?
