When designing my scripting language, I stumbled across this block and I've been thinking about it for the past few days. You see, a scripting language is suposed to be high-level and easy to pick up, code and debug. So pointers are a no-no. However, they are really powerful and the scripting language could be a lot more powerful with them. It's a tradeoff between power and ease of use. I came up with a few simple rules that *might* be a good compromise between both extremes, but I'm not sure. I'd like your opinion on whether I should use one of the 3 or if there's a better way. This is aimed for games by the way. The native numeric types are always passed by value (this is easy to accept; arrays, lists and such are dealt with using the second method). The other variable types, or object classes, can be flagged as either volatile or persistant. A volatile variable is much like a string; it's a pointer to an object, starting with a new default object, and when assigning a volatile variable to another one, it's data is copied to the second variable (they don't point to the same area in memory). Again, its rules are akin to a string's. This can be used for temporary or global variables like strings, lists, arrays, etc. A persistant variable is a pointer to an object that exists in the game world. That's it; it doesn't need to manage memory in any way. The only exception is that there's a system that prevents wrong memory accesses if an object is destroied. You can create a variable "player" to point to a specific player, and later assign this to another variable so both of them point to the same thing. They start uninitialized (pointing to nothing). This is a bit specific to the gaming world, but that's why I don't simply use a general purpose language. Do you think this is a good system? Or I should go with either pointers, or no pointers. Thanks :)

I'd suggest instead using references and a garbage collector, like in Java or C#. Pass primitive types (int, float, etc) by value, but only pass objects by reference.

A reference is just a pointer that you can't treat like a number - you can only access the object it refers to, test two references for equality, and assign a new value or "null" to an existing reference.

Garbage collection can be done accurately and fairly easily with the "mark-sweep" algorithm. Every so often (maybe when you have more than X total memory usage for script objects), do the following:
- Stop any running scripts (very likely you'll just have an event system and no permanently running scripts though)
- Mark all objects as "garbage"
- For each global object (and each object on the stack on a currently executing function, if you had a running script), mark it as "not garbage", and recursively mark all the objects it refers to as "non garbage".
- Delete all objects that are still marked as "garbage".

If users can't define custom classes, it's probably possible to implement an even simpler garbage collector, using simple reference counting.

That's what I was trying to say, but I guess I explained myself poorly :)

The only addition I made was the distinction between 2 types of references: the ones for game objects, like you said, and the ones for abstract structures like lists and strings. This way the pointers are nicely hidden from the scripter, who never really has to deal with them. I just wanted to discuss this idea. Thanks :)

If if you could pass a pointer to your script, you'd still need routines to access the data of the object the pointer's looking at. With numbers and strings this is fairly easy, but if you're looking to port C++ classes and other datastructures into the script it's not so simple. You'd still need to have an interface layer that the script can use to reference the members of your class and store/retrieve the data appropriately from them. Assuming you do that and a script knows which class member to access for a given operation, it's still fairly risky unless you do a lot of bounds checking on the data. Simply, I couldn't trust a script with free access to a pointer.

I would suggest making certain types immutable (i.e. like strings, numbers, vectors), but make everything else pointers. For example, if someone inits a class "p = new Player()", and then says, "p2 = p" p2 and p both point to the same location in memory (i.e. a pointer), but lets say "n = 5; n2 = n" In this case, n, n2 are in two different memory locations (because the number was immutable).