Returning Arrays in Script

#1 It's not.
Your reasonable choices are:

1) Create an object and slap your array inside of it. Remember to delete said object:

function x() {
  %t=new ScriptObject();
  %t.x[0]=1;
  %t.x[1]=2;
  %t.x[2]=3;
  return %t;
}

$x = x();
echo($x.x[1]);
delete $x;

2) Pack and unpack the array in a string:

function x() {
  %x[0] = 3;
  %x[1] = 2;
  %x[2] = 1;


  %ret = %x[0];
  for(%i=1;%i<=2;%i++) {
    %ret = %ret SPC %x[%i];
  }
  return %ret;
}

$x = x();
echo(getWord($x,1));

Gary (-;

#2 edit: doh! beat me to it, Gary! - it's reassuring that we came up w/ pretty much identical code.

You are correct, that will not work.

w/ stock TGE, you could do something like this tho:

function x()
{
   %ret = new ScriptObject;
   %ret.x[1] = 2;
   %ret.x[2] = 1;
   return %ret;
}

$ret =  x();
echo($ret.val[1]);
$ret.delete();

alternatively, i see you're an SDK owner, which means you could implement a real array class. i hear there's a resource for that.

#3 Alright, I thought so, I already had a work-around in mind but I was hoping I wouldn't need to use it.

Thanks for the quick response.

#4 There's also the global variables approach. Sucks, but it all depends on what you're using it for.

Gary (-;

#5 Yeah, I knew that - that would defeat the purpose.

#6 Gary whats wrong with using global variables for it? is that less efficient or wasteful?

#7 Same thing that's wrong with global variables anywhere else; they suck.

Also, torque has been slowly leaning towards multithreaded/concurrency. Global variables without a mutex primitive are bad, mmmkay. At least for now, torquescript is still exceedingly single-threaded, but if that changes, then global variables are the first thing to break.

Gary (-;

#8 Interesting...what would be the best way to handle constant values in script? In my script I need to access constants from multiple areas and methods in script, so if globals are no good....?

#9 Not necessarily for you Gary but a question for anyone who cares to answer.

I've heard from lots of places that it's generally bad practice to rely too heavily on globals. would it better to use an object instead? like this

$globals = new scriptobject()
{
      status = running;
      stage = 1;
}

instead of using individual global values, you would have one value which is a reference to a global object, $globals, and access its properties like $globals.stage. would this be better than using individual global values?

#10 Rubes - for read-only constants,
i wouldn't hesitate to use globals.

Just for tidiness i would probably put them in namespaces tho, like $Constants::foo.

#11 @Orion: Ah, excellent. I had hoped so, thanks.

#12 If you're defining the constants in C++, there's a sorta fancy thing you can do, but if you're defining them in script it doesn't really make sense.

#13 Interesting...so if you need a variable (not associated with a particular object) that you must access and modify in multiple places in script, what's the best way to approach that? Create the variable in C++ and then expose it to script?

#14 @Sean: Generally global variables are thought as bad because they can complicate comprehension of code and hide interdependencies. They also are very nasty for multithreading, which is not necessarily applicable for TorqueScript. They are not inherently bad and are necessary in many situations, but should be used with caution.

One example in TGE why you should be careful of globals is co-located server/client. Is that variable specific to the client or server? If so you can accidently reference it in the other and get very strange behavior. Generally if a variable needs context to make sense it should be made local to that context to avoid these types of situation. Put plainly the scope of your variables should be as narrow as possible, don't define a global variable when you can do it locally to an object or function.

Here are some quick links I googled up about it.
en.wikipedia.org/wiki/Global_variable
www.bic.mni.mcgill.ca/~david/volume_io/section2_4_1.html
mail.python.org/pipermail/tutor/2002-December/019072.html

Just google "Why are global variables bad" and you'll turn up many more. Those are just a quick few I scanned first.

#15 @Rubes: Global variables are represented by $name. They're just *there*. You can easily access them from anywhere in script, or from C++ with {redacted because this is a public forum}. Torque does have global variables in the sense that you'd expect of normal global variables.

@Constant thoughts:
I can't find a link immediately, but I remember seeing a while ago someone using their C preprocessor for constants and includes in torquescript.

Use #define and #include in your torquescript source, and then run it through your C/C++ preprocessor before running it.

Gary (-;

#16 @Gary: I got that, yes, and that's how I currently use them. But you're saying how global variables in script are basically bad, and how they would be especially bad if torquescript ever does become multithreaded. So I'm just wondering how, then, one might best approach the need for (and use of) global variables in script in a way that wouldn't be bad.

My game is exclusively single-player, so I'm not as concerned about values on clients vs. server, but I do see how that is potentially a Bad Thing.