in reply to Imagination greater than reality?

The solutions from huck and 1nickt look fine to me. Note: BrowserUk's idea about require is also applicable to this problem.

I don't know whether you need the flexibility of different algorithms between states or just different parameter values, like "state sales tax" or whatever.

A different approach to consider might be the SQLite DB. This DB uses a simple file instead of a separate SQL server process. It works very well (I think every smartphone has a SQlite DB). The Perl DBI for SQLite is excellent and I've used it on a number of projects; some small and some with millions of records. Your module could access the DB to get values for whatever state you tell it you are in.

Also one point to consider is maintenance. In general maintaining a single US DB is probably easier than 50 different state specific modules expressed as Perl code. I know very little of your actual application. If this sounds like it is worth pursuing for you, happy to provide more information and suggestions.

Update:
Another try at an explanation: If you can express the functions for each state as a single set of "code" with 50 different sets of "data", I would recommend the DB approach even if this complicates the code logic in this "single set" of code. If you have 50 different sets of code, that can vastly complicate the maintenance.

What you apparently want to do may adopt itself well to an OO paradigm. The user program says: "use StateFormulas;". When creating a new StateFormula object, specify the state. When the object is created, data is read from the DB. This object for say TX (Texas) now works differently than one for say IA (Iowa) because of differing parameters. If say the Texas calculations are somehow different because it has a coastline, then I would put a field in the DB like "has_coastline". The code will perhaps wind up some "if" statement, but that if statement will apply to all states with a coastline. If you go this way then code could wind up with easy comparisons between different states because each object in the program would be specific to a state rather than saying "hey now this program works specifically for TX". Hope this helps.

Replies are listed 'Best First'.
Re^2: Imagination greater than reality?
by RonW (Parson) on Jul 17, 2017 at 23:30 UTC
    I don't know whether you need the flexibility of different algorithms between states or just different parameter values, like "state sales tax" or whatever.

    FYI, some states have local as well as state-wide taxes. Also, different categories are taxed differently in different states, sometimes even different local taxes. I would not be surprised if it were significantly easier to write code for each state than to try to devise a set of tax tables.

[reply]
      I would not be surprised if it were significantly easier to write code for each state than to try to devise a set of tax tables.
      Actually I would expect that maintaining 50 different sets of code would be significantly more effort than a single set of code with a DB, even if the code is significantly more complex to write in the first place. 50 different algorithms is a difficult thing to get one's brain around. If say some flaw is found in the Texas algorithm, then it could be a big problem figuring out which of the other 49 sets of code are affected.

      Another factor can be just the on-going updates of the per state information. I doubt the OP is working with "sales tax" - that was just the first obvious "per state" idea that popped into my brain. There are companies who specialize in DB's and software to deal with the complex plethora of US tax laws. A long time ago I had a friend who was a salesperson for a company like that. What multi-state and multi-national companies do with this tax stuff is super complicated and worth "big bucks". For a number of reasons, "roll your own tax code" is not a good idea. My mention of this was just a "for instance, example", not anything deeper than that.

      Back to the generic programming issues... Whatever it is that changes between the states, a solid program "product" will have a way to keep things "right" and "updated" past the first program release. As a dev engineer, I want to write new code that solves new problems. I can't do that if "my released product code" is not maintainable or extensible by somebody else.

      I have no problem with the solutions to the OP's problem which address it directly - they look fine to me. My goal was to present another possible approach to the OP's problem.

      One issue is "hey, its been 2 years, how do I know that this per state stuff is "up to date"? How does somebody get "notified" that something needs to change for Texas? As another issue, an OO paradigm seems like a good idea here. I would not put knowledge of the states into the stateObject. I would use some parameter like 'TX','AX','NTX'(North Texas) when creating the "StateObject" and give a clear error message comprehensible to the expected "user". The new StateObject looks into the DB and initializes its behavior based upon that. If Puerto Rico, PR ever becomes a state (which it probably won't), add another line to the DB. The testing code can make 50 different state objects and run the same data against those objects and compare results. A situation where the program starts and then is "customized" to a specific state is not as flexible of an approach.

      From what I have read, the OP is proceeding with a solution that works for him. Fine. There is often "more than one right answer" here. My comment are for others who may follow with similar issues.

[reply]

        I do agree that parameter-izing generic code is preferable to coding each case. I also know that, sometimes, it's clearer and cleaner to "code the cases". (And even then, I still try to parameter-ize a lot of the code into call-able functions.)

        Out of curiosity, I asked one of our IT department's database gurus if she knew anything - or knew anyone who knows - about tax rate databases. 2 of her colleagues at other companies do work with tax databases. She told me that they use a lot of "stored procedures" and triggers to calculate the applicable tax rate for a significant majority of the scenarios the databases cover. Their rational is that this greatly reduces the complexity and size of the databases. Also, that even if they had to deliver a database with no stored procedures, they would have to write similar code to generate the parameters to store in the "pure" database.

[reply]

In Section Seekers of Perl Wisdom