The singular point of global variables is that they store values accessible to anything else. You can get around that with arrays, but the larger the array, the more time it takes to read it. That's the painful trade-off.
I don't see why this would be true. Arrays are random-access objects, and accessing elements of an array is a constant time operation. It doesn't matter how large your array is, so long as it is smaller than, say 2^32 items or so.
Maybe you are thinking of linked lists?
'Functions don't store anything, by nature. You cold probably return a value, and exchange it between two functions, perpetually, which would act like storing it, but that would be horribly limited, convoluted, and potentially crippling.'I admitted, before posting the model, that it probably wouldn't work--or if it did, it would break ZC--but I figured I'd try it, to be certain.You're essentially re-enforcing my points above; but rather than discounting it out of hand, I tried to conceive of a method that might do this. It doesn't bother me that it didn't, and there may be a way around the problem, but it;s a terribly hack-ish, and fruitless exercise.
The thing is, this method of storing a variable always keeps it on the stack and only visible to the function that put it there, so how is it different from a local variable? Unless you can pass a function (with a closure) as a parameter, you're getting nowhere.
If you could do that, then you've got something that will work, but then you've got a functional language. And functional languages technically doesn't need any mutable variables whatsoever.
If you want global variables that don't save, just reset them when your script starts up. If you don't want them to count against your limit, store them in arrays or make them const.
The only other way I can think to mimic this idea is to have a function in your global script that maintains a single global variable as a 'register', and functions that process requests load and store values from that register. The idea being that you would set a switch, and the next time that part of your global script runs, you would be able to read the requested value from the register after you call waitframe().
However, this is not worth the effort. It's still using local variables, and it still uses at least one global variable. It also breaks good design principles, because the functions would have to be rewritten to declare new variables. It is far less confusing and more efficient to just use arrays instead, indexing values with constants.
Edited by RetraRoyale, 10 June 2014 - 04:26 PM.