Thanks for your comments, gaal. It sounds like you're leaning towards one of my first ideas ("pulling all of the %data hashes out and combining them [into a global hash], then passing a hashref ($data{$type})" (even if it is implemented with an OO approach).

1. There is one registry. Make it global.
This was my first inclination, but I was torn between that and keeping the data elements localized to the sub they are used in. I thought it would be easier to understand the code if the data was right there next to it, but maybe I'm better off keeping all the data together.

2. ...these functions should get the type (probably by name -- that's easier), and know about the registry.
Currently, the names of the "types" are the top-level keys to all the hashes, and that is what I pass as a parameter. If I combined all the data hashes per comment #1, I could pass $data{$type} instead. This would limit the portion of %data that is accessible by the functions to only the entries under the specified $type key, and it would eliminate the need to pass either $type or a ref to %data (although the latter would not be necessary if it were a global, as you point out).

3. You need generic functions for manipulating the registry too. You'd mentioned adding a new type;
I wasn't very clear about this in the OP - sorry. The different "types" (top-level keys) actually represent different data files, and the functions are used to manipulate and search through them. It is possible that new data files could be added to the list, but that would be a very rare occurance and I assumed it would be easier just to add some entries to the %data hash(es) rather than develop a set of functions to do it for me. You raise a good point, though - I'll give that some thought.

4. This suggests a class (though you don't have to go OO all the way if you don't want to).
I started thinking about using objects (and their advantages), but I'm still very new at OO programming and I haven't totally thought out how I could/would/should structure things. Nonetheless, I do like the idea of having the guts encapsulated behind a defined interface. I think I'll have to spend more time considering this approach.

Thanks again for the comments. It's nice to have a few different ideas to consider.

In reply to Re^2: Structuring code by bobf
in thread Structuring code by bobf

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.