Keeping in mind that laziness is a virtue, for the type of data I think you're talking about (description of standard data structures that change infrequently, if at all), I think I'd probably use the simplest method (#1 or #2) to start with. In other words, get in, get the job done, and move on. Chances are very good in this case that you'll never have to go back and change it. If you never need to change it, any effort expended to generalize it would be wasted.
If at some point in the future, you do need to change it, you'll be better positioned for deciding how to improve it. If it's five years later and you're making a very simple change that doesn't require you to handle multiple versions, you could just update the data structure and move on again. If there are more drastic changes, you might decide to switch to a more general solution (#3 .. #5).
For stuff you know is going to change soon, all the options you listed are reasonable. If time is really tight right now, you might choose #1 with the intention of upgrading to a better method later. However, this would incur some "technical debt" for your project. If you're in a shop that never lets you pay down your technical debt, then do it the best way you can the first time to avoid that debt. Otherwise you'll dig yourself a hole you'll have trouble climbing out of.
...roboticus
Just one robots opinion...In reply to Re: Including periodically changing data with modules
by roboticus
in thread Including periodically changing data with modules
by hangon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |