Global scope data and recursion in the CC shell

Hello. I'm usually pretty casual about global usage. My instincts (from using lua as a scripting language) are to leave things global unless I have a definite reason to limit their scope.

But I'm thinking about writing programs that may call themselves or other programs I've designed, and it seems like this could start getting me in trouble. On the other hand, sometimes I need something to be global in order to work. So, here's what I think I know about when to use global scope.

1. When defining a table of functions that have to be accessible to various scopes, and will not be altered during runtime.
2. For a table of data that will be created by one program and only referenced by other programs, which will need the data in order to interface with functions defined by the first program.

So, am I horribly mistaken and everything will go pear-shaped if I use global data this way?

You should always try to make variables local.
Not only does it make your program easier to understand, but the overhead of accessing a local variable is less than that of a global variable.

Edit: Data encapsulation is your friend!

1. A table of functions is essentially Lua's version of classes. The functions within the table must remain global in order to be accessed from the oustside, but the table itself should be made local and should not be contained within any other functions.

2. I do not fully understand your explanation of this, but it sounds a lot like your first scenario, except more in-depth. It seems you need a class with a constructor.

Hmm…when I make my tables of functions local, they stop working with other functions. Is there a good way around that?

You have to declare the local tables before defining the functions that you want to access the tables for the functions to be able to access them.

ChunLing, on 19 October 2012 - 09:00 PM said:

Hmm…when I make my tables of functions local, they stop working with other functions. Is there a good way around that?

Or just put it in an API file and use os.loadAPI.

Yeah, that's part of the problem. Here's the pastebin link. Right now I've left a lot of the tables global, because the program works fine that way. But I can make most of them local. The problem is tfnctns, starting at line 99 in the linked code. If I make that local, then the gox function can't be called, cause it needs tfnctns[6].

Should I just move that function somewhere else? Cause it calls a bunch of other functions, and I'm not sure how to maintain functionality (particularly the ability to call it through the remote interface) without giving it the scope it now has.

Hah, ninja'd. Yeah, an API is the normal way to handle this. I didn't want to before because I wanted the program to be a self-contained utility, maximal ease of use/installation. But probably I should work it up as an API.

You can use getter and setter functions from within the same scope as the local tables. Any methods that need to access the table can indirectly access through the global get/set functions

Hmmm…that's good but doesn't really solve the issue of function scope, which is the real difficulty.

You can just pass the object it needs into the function.

Ah, functions as objects. I'll get around to trying that eventually, right now I'm working on a different (but related) program.

Turns out all I needed to do was make a local declaration of the table (and any string indexes) before defining the functions it contained. Then the other functions have somewhere to point to when they want to access functions in that table, and I can define those functions after the functions that are needed for the functions in the table. The benefit I was getting out of having that table be global was simply that it was being reserved before all the local stuff was defined, even though the functions didn't get put in till later.

I hope that made sense. I'll be posting the modified code after some more testing.