I see what your're saying now. It's more object oriented when things like the array are stored elsewhere.Aacini wrote:Samir wrote:In my original thinking, an array is the other data structure I was thinking to store the product/moniker table in and then somehow retrieve that. But updating the table if anything changes is still a chore--and it's a chore no matter what format we store the table in since it would have to be updated. Hence why I chose the route to just hard code it.
(Anytime a product would have to be updated, so would the moniker. In hard-coding, just the moniker would have to be updated. This also gives some flexibility as a small product change like Ice to Ice Bags would not require that the script be updated so long as it still corresponded with the same moniker.)
I am afraid I don't understand your point. If the table needs to be updated it requires just one change: if it is in the program, change the program; if the table is in a data file, just change the data file. For example, this could be the table:Code: Select all
Unl-Self=Fuel:87
Ul-Plus-Self=Fuel:89
Supreme-Self=Fuel:93
Diesel-Self=Fuel:Diesel
Candy=Non-Fuel:Candy
Coke Product=Non-Fuel:Coke
etc...
... and this table could be loaded into "moniker" array this way:Code: Select all
for /F "tokens=1,2 delims==" %%b in (monikerTable.txt) do (
set "moniker[%%b]=%%c"
)
This method have the advantage that you may use the table for other things; for example, you may sort it alphabetically, or add prizes to it, etc...
Antonio
The problem is that I've already hard-coded most of the other elements in the other batches that work with this one. I'll still be updating everywhere if anything has to be changed.
And when that change comes, it's going to be so dramatic that I'll probably have to scrap all this work for a completely new system. But when it comes time to code for that new system, I'll try to use what you're saying for sure.