Hide the complexity behind an interface.
package My::FieldMap;
our %INTERNAL_VALUES = (
'foo|bar' => 'fb_val'
);
our %INTERNAL_NAMES = (
'foo|bar' => 'fb_val'
);
sub _build_key {
return lc( join '|', @_);
}
sub get_internal_name_value {
shift if $_[0] eq __PACKAGE__; # Can call as pkg method
my $ext_name = shift;
my $ext_value = shift;
my $composite_key = _build_key( $ext_name, $ext_value );
# probably want to put some error checking code here.
# What do you do if called in scalar context?
# What if one or both keys don't exist?
return (
$INTERNAL_NAMES{$composite_key},
$INTERNAL_VALUES{$composite_key}
);
}
Use it like this:
my ($in,$iv) = My::FieldMap->get_internal_name_value( $ext_name, $ext_
+value );
# or
my ($in,$iv) = My::FieldMap::get_internal_name_value( $ext_name, $ext_
+value );
Now, when you have to deal with millions of field/name pairs, and you move to Redis or memcached to store them, you just have to update the lookup function.
A good interface with horrible code behind it is 10000% better than the most elegant snippets sprinkled everywhere.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.