Altering function arguments?

Thalassicus

Bytes and Nibblers
Joined
Nov 9, 2005
Messages
11,057
Location
Texas
I just want to check... arguments cannot be altered in lua, right? In other words this sort of simplification isn't possible:

Code:
function Init(tableName)
  if not tableName then
    tableName = {}
    return true
  end
  return false
end

if Init(Game.SomeNewTable) then
  ...
 
Tables are pass-by-reference. So, setting argument = {} might just change what table the variable argument points to (or it might actually empty the table, I don't know, it depends on how it's defined). However, I think there are way to empty a table, which would work as long as they are applying to the table itself.
 
Well what I want to do is actually initialize the variable as a table value only if it hasn't already been initialized. If I print the type of SomeNewTable after passing it to the init function it's nil.
 
Well what I want to do is actually initialize the variable as a table value only if it hasn't already been initialized. If I print the type of SomeNewTable after passing it to the init function it's nil.
Yeah, that would be harder, as only table parameter values are passed in this way. You can't set a variable like that per se. The nearest thing is to pass a table and only examine a single member of it. So receive a table as args, and both the function and the table look at args.something... I'm pretty sure.
 
It basically comes down to the difference between a variable and a value, and (apart from typing) it's actually much like Java, with tables as the only reference type.
 
I check for tables often with a simple if, and I doubt it would increase your runtime much to try that way.

Code:
if Game.CustomSettings then
	functionwithyourcode()
else
	Game.CustomSettings = {}
	functionwithyourcode()
end
 
I check for tables often with a simple if, and I doubt it would increase your runtime much to try that way.

Code:
if Game.CustomSettings then
	functionwithyourcode()
else
	Game.CustomSettings = {}
	functionwithyourcode()
end
I think the aim is to do it in the function being called, which produces cleaner code... the usual pattern for such a thing in Java is for the variable to be in the called context (not special meaning of context, just general), and to have a call to get it that initialises it if it isn't yet set:

Code:
function getTable()
if table then
  table = {} -- or whatever
end
return table
end
 
Right, basically my goal was to make the code look a little less messy with a single Init(variable) replacing the if-then block (or x and y or z trinary block) to initialize things.
 
A bit late maybe but why not just use a global and set t = t or {} to initialise when you need it? Another option closer to what you were trying to do is to use a function with a return value:

function init(t)
t = t or {}
return t
end

t = init(t)
 
Tables are pointers, so the internal t would go out of scope and turn the external t nil. :)

The reason the t = t or {} doesn't work is because I also want to do certain tasks if t hasn't been initialized yet, so it requires an if-then block and is just a bit messier looking.
 
Tables are pointers, so the internal t would go out of scope and turn the external t nil. :)

The reason the t = t or {} doesn't work is because I also want to do certain tasks if t hasn't been initialized yet, so it requires an if-then block and is just a bit messier looking.

No, because as soon as you return it, it will be available in the global scope if you assign to it. You are right when speaking about your code, but mine works a bit different. You can also use

function init(t)
return t or {}
end

which is actually a bit clearer.

Edit: In other words, the closure only kills local variables that aren't returned.
 
Huh, I could've been positive a bug I had a few weeks back was due to something like that... oh well! :crazyeye:

Though there's still the thing that I want to be able to check if it's been initialized or not, while simultaneously doing so... otherwise I'd just use the or {} everywhere.
 
Really, tables aren't pointers like in C - they're references like in Java. The scope of the original creation of the table itself isn't relevant - what is relevant is if any variable refers to it and is in scope, and a returned thing counts long enough to assign it. Similarly, a global counts.
 
Well, technically both c++ and java have both pointers and references... just differences of implementation and how accessible the underlying pointer is.
 
Back
Top Bottom