Illusive Array Overwriting Itself

[pwniknoobz]

I have this code:

Code: Select all

StageArray = {}

StageArray[0] = Stage:new()
StageArray[1] = Stage:new()

StageArray[0]:setParams(txtBoxes_Stage_0,btnButtons_Stage_0)
StageArray[1]:setParams(txtBoxes_Stage_1,btnButtons_Stage_1)

When I then call the elements of StageArray[0], they are the elements of StageArray[1]. Any ideas as to why Lua would be overwriting the values of the first array with the second one?

This is stage.lua:

Code: Select all

Stage = {txtBoxes={},btnButtons={}}

function Stage:new (o)
	o = o or {}
	setmetatable(o, self)
	self.__index = self
	return o
end

function Stage:setParams (txtBoxArray_Stage, btnButtonArray_Stage)

	self.txtBoxes[0] = txtBoxArray_Stage[0]
	
	for i=1, txtBoxArray_Stage[0] do
	
		self.txtBoxes[i] = txtBoxArray_Stage[i]
		
	end
	
	self.btnButtons[0] = btnButtonArray_Stage[0]
	
	for i=1, btnButtonArray_Stage[0] do
	
		self.btnButtons [i] = btnButtonArray_Stage[i]
		
	end

end

function Stage:draw ()

	drawTextBoxes(self.txtBoxes)
	
	drawButtons(self.btnButtons)

end

function Stage:mousePressed (x,y)

	checkTextBoxesClicked (self.txtBoxes, x, y)
		
	checkButtonsClicked (self.btnButtons,x,y)
	
end

function Stage:keyPressed (k)

	updateTextBoxesText (self.txtBoxes, k)

end

I also tried it without an array, and it seems like everytime I call setParams for Stage, it overwrites all of the objects for the previous stage that I called setParams for...

[nevon]

Lua uses a base index of 1, so the first element of a table is 1, the second 2, etc.

[pwniknoobz]

Tried it with index numbers 1 and 2 instead of 0 and 1. It seems whichever Stage[index] calls setParams last redefines all of the ones before it..

It is possible to make a table an attribute of a table, correct?

Just to clarify: txtBoxes_Stage_1, btnButtons_Stage_1, txtBoxes_Stage_0, btnButtons_Stage_0 are all arrays I'm attempting to pass into the Stage array.

[bartbes]

I'm pretty sure it's your setParams function overwriting it. (it has to be)

[pwniknoobz]

Thanks for the help everyone - I actually decided it was kind of pointless for me to make a stage class, because for every object I created I'd have to modify the stage class to make it use the respective draw/user input functions of the new class. It is much more practical for me to just make a supplemental external function in which to handle all of the drawing. I will just keep track of staging for objects via a 2 dimensional array, i.e. Object[j], where i is the current stage. Event handling for the objects is simply based on a conditional statement tracking the current stage(global variable). In this manner I don't have to worry about an additional unnecessary stage "object."

[pygy]

All your objects were sharing the same metatable index (the Stage table).

As such,

Code: Select all

self.txtBoxes[i] = txtBoxArray_Stage[i]

was always populating the same subtable (Stage.txtBoxes), overwriting any pre-existing value.

[osuf oboys]

Thanks for the help everyone - I actually decided it was kind of pointless for me to make a stage class, because for every object I created I'd have to modify the stage class to make it use the respective draw/user input functions of the new class. It is much more practical for me to just make a supplemental external function in which to handle all of the drawing. I will just keep track of staging for objects via a 2 dimensional array, i.e. Object[j], where i is the current stage. Event handling for the objects is simply based on a conditional statement tracking the current stage(global variable). In this manner I don't have to worry about an additional unnecessary stage "object."

You get a lot of power from keeping it as objects, such as a good place to keep common functionality, inheritance, decoupling, and the possibility of pausing or stacking stages. If you are uncertain about whether the OO stuff will work out, maybe it will feel safer for you to abandon it but I think they functionality and experience will be beneficial in the long run. Anyhow, the issue was as pygy said although let me rephrase it because I'm not sure it was understandable.

The thing is that you had a table such as

Code: Select all

class = { x={} }

and created two objects that used this class

Code: Select all

object1, object2 = {}, {}
setmetatable(object1, class)
setmetatable(object2, class)

Now the metatables work as such that if you query an element of the instances that does not exist, it will look in the metatable/class instead.

If you create a new variable with

Code: Select all

object1.y = {1=3}
object2.y = {1=4}

the two instances will create their own distinct variables and things work as you want them to.

Code: Select all

print object1.y[1]
>> 3
print object2.y[1]
>> 4

Changing the variable also works as you expect since they are stored in the object1 and object2 tables, respectively.

Code: Select all

object1.y[1] = 5
object2.y[1] = 6
print object1.y[1]
>> 5
print object2.y[1]
>> 6

However, with

Code: Select all

object1.x[1] = 3
object2.x[1] = 4

Lua will look for 'x' in the object1 and object2 tables, and if it cannot find it, in the metaclass. So "object1.x" will return "class.x" and the same applies for object2 and hence they change the same array.

In other words, the OO analogue of "class = {x = {}}" is not to declare an instance variable but rather a class variable.

[Robin]

Here's a quick and simple solution:

Code: Select all

class = {}

function class.new()
   return setmetatable({x=3}, --blahablabha, metatable. you know the deal
end

You can make endless variations on this theme.

[bartbes]

You guys just keep forgetting __index...

[osuf oboys]

You guys just keep forgetting __index...

Is your TI getting a lot of attention? Pedagogy != regurgitation .