The thing is you have to decide if you want static or dynamic arrays, easy choice there you want dynamic array because you have no idea how many variable - value pairs you will have to store.
Then there is question to SHARED the arrays or not. Here is the big decision, I decided to SHARED the arrays in oh interpreter because you don't want to pass arrays as arguments unless absolutely necessary.
Once I decided on SHARED the rest of the decisions were easy to decide:
Deciding on SHARED that means you have to design application specific subs and functions to handle the specific arrays so since I had to do that, I might as well use list type arrays because generally they are easier to type without all the dot stuff you have with UDT's.
And further, I decided on base 1 arrays because then the Ubound of the array is also the number of items in it, just to make things a little bit easier on myself.
So, while RC works on theory, that works for most cases generally, when it comes to actual application you want a fast efficient program easy to read, understand and modify.
So there, I think I have recreated the decision process I went through using an actual application of dictionary type structure in oh Interpreter.
Oh and you know what? You don't have to worry about initializing string arrays as you do with values in UDT's, though it may not matter with variable values tables.
So proceeding here, we have to talk generally with dictionary arrays so we need to pass them as arguments as TempodiBasic has begun. Using UDT's ??
Don't know if I want to proceed down that line, yeah UDT's might be better if we have to pass the Dictionary arrays!
Yeah! That surely beats having to pass 2 arrays! 1 for the keys and one for the values.
