46 replies to this topic

[RetraRoyale]

 

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.

[Timelord]

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

I seem to recall that ZC reads elements in a linear order, and not R/A--which although not typical, I understand it to be a specific limitation for ZC. If that's incorrect, then it only further supports my model, for using arrays, in favour of global vars, whenever possible.

That's something that would need developer clarification.
 
 

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.

I should clarify, that I tried this, just to see if it would work. Ultimately, it's no different than a local variable, except that if it did work, and could be done in a fully external scope (using external functions), then the global active script would be passing a vale between those functions, that could be modified by other external functions (essentially, like using a subroutine), or read by any external programme/script, via a third function called in that programme/script.

The theory was, that a third function, would be importing the value being constantly shifted and returned, into any local scope. (i.e. Because the functions passing the value are external, and because the function that would read, or change the value is external; then anything could call the function to read, or change the value being perpetually passed.)

That would be the only practical advantage, over a local variable:

As the method itself proves not to work; and as there's not much of a point to furthering any work on forcing it to work, because its use is so bloody absurd, it doesn't bear much further contemplation on my behalf; but I decided to see if it was even a valid concept, which 'tisn't.

A more practical concept, assuming that you know that your variables will never exceed a specific numeric value, would be to read segments of values, and set segments of vales, by numeric place. The setting part, becomes a bit messy, but reading is simplistic.