This is a question on how javascript (or at least sphere/minipshere's implementation of it) handles scope when it comes to arrays and objects; this may just be a problem arising from my scripting/programming knowledge being 90% self taught - I don't know how some of these things work.

Suppose I create an array inside a function:

Code: [Select]

function my_func()
{
  var my_array = [];
  ...
}

Now further suppose I wish to update that array inside another function:

Code: [Select]

function other_func()
{
  ...
  my_array[2] = 5;
  ...
}

Obviously this will not work as the array is not in scope, now let's suppose instead I pass the array as a parameter to other_func:

Code: [Select]

function my_func()
{
  var my_array = [];
  other_func(my_array);
  ...//do something else with my_array which relies on the 3rd value being 5
}

function other_func(param)
{
  param[2] = 5;
}

The second function will now not have a scope problem, but I think I'm right in saying that back in the first function will also have that value of 5 available to it, is this right? And is it appropriate to rely on this behaviour? I had instead been intending to have other_func return the array after updating it and have my_func overwrite the array with the returned one - is this functionally different?

Code: [Select]

function my_func()
{
  var my_array = [];
  my_array = other_func(my_array);
  ...//do something else with my_array which relies on the 3rd value being 5
}

function other_func(param)
{
  param[2] = 5;
  return param;
}

Is either of the above suggestions better than the other?
Is there any difference if the array is a property of a different object and you pass either the full object my_obj or just the array my_obj.my_array as a parameter?
Can getting this wrong create memory leaks?

In JS, arrays, like objects, are passed by reference (well... technically it passes a reference by value, but that distinction is not important in this case).  So if you modify its contents in the function, the calling function will see the changes directly.

What I mean about passing a reference by value is that modifying the object passed in will be visible to the caller, but reassignment will not:

Code: (javascript) [Select]

function f1()
{
    var arr = [];
    f2(arr);  // what is arr now?
}

function f2(arr)
{
    arr.push("pig");
    arr = [];
}

After calling f2() arr will an array with one element, the string "pig".  NOT an empty array.

As for memory leaks, it's pretty much impossible to leak memory in JS, since the JS engine frees objects automatically once they go out of scope (eventually).  You don't have to manually track allocations etc. like in C/C++.  There are no pointers in JS.

I've made memory leaks in Sphere before - you just have to find a way of continually bringing more objects into scope without letting old ones go out of scope, a while back I scripted a game menu with various sub menus, if you closed a submenu it called the game menu function again - the original instance of it was still open, so if you went in and out of sub menus without closing the whole menu you would burn up your memory pretty fast. (there were several other things wrong with that script - it was loading various graphics files for the menus only when they were called - which in this case meant the potential loop was loading those graphics files over and over.

if the graphics had been loaded once at the start of the game the problem would have become unnoticeable.

OR if the functions had terminated properly and dropped back to a controlling function that would then call the next function rather than trying to call the next function themselves the problem would have been avoided.

Either way I've learnt that you can make memory leaks in sphere and with the pieces I'm looking at at the moment the functions I'm using to update arrays are being called repeatedly - potentially every frame, and so if I'm accidentally duplicating the arrays and not letting the duplicates drop out of scope it could be bad...

I guess that's true, but at least in that case you can track where something is still holding onto the object (because it's still in scope, somewhere).  It's a lot easier to debug that situation, in my experience, compared to leaking pointers, where both you AND your program have completely lost track of the object.