Problem using the 'SECS' class library

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Lafolie
Inner party member
Posts: 809
Joined: Tue Apr 05, 2011 2:59 pm
Location: SR388
Contact:

Re: Problem using the 'SECS' class library

Post by Lafolie »

A lot of work was put into Lua so that you don't have to do this kind of thing. The garbage collector is actually really effective in Lua, and if that's not enough then weak tables further prevent the need for destructors.
Do you recognise when the world won't stop for you? Or when the days don't care what you've got to do? When the weight's too tough to lift up, what do you? Don't let them choose for you, that's on you.
User avatar
markgo
Party member
Posts: 190
Joined: Sat Jan 05, 2013 12:21 am
Location: USA

Re: Problem using the 'SECS' class library

Post by markgo »

This is actually quite simple:

Code: Select all

test = {}
test.name = 'test'
function test:destroy()
  _G[self.name] = nil
end
test:destroy()
print(test)
Replace _G with a table that you're storing your object in.
Last edited by markgo on Fri Apr 19, 2013 11:45 pm, edited 1 time in total.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Problem using the 'SECS' class library

Post by kikito »

Zephos wrote:Let Y be the main problem here now. My X should be irrelevant for you as long as I know exactly what I want, anyway. Just please give me the answer to my problem and let me be happy, especially if the solution is exactly as easy as I imagined it to be:

Code: Select all

function object_destroy(objstr)
	loadstring(objstr .. " = 'whateverthefuckiwant'")()
end

...

object_destroy("obj")
Now, is there anything to complain about this? In the end, that's all I wanted to know.
You can not do what you want. Let me try to explain this.

When you assign a variable to a value, for example local a = {}, you create a reference to it.
When you pass a variable to a function (for example by calling foo(a)), you are creating a second reference to the same value. While foo executes, your program has two references to the table. When foo finishes executing the second reference is eliminated, unless you return it or save it somewhere else.
This means that it doesn't matter what you do to the variable inside foo; the variable "outside" foo still exists - you are just modifying a second copy. In other words, your code is doing something equivalent to this:

Code: Select all

local a = {}
local b = a -- create a second reference
b = nil -- b is nil, but a still points to the table
Since your program still has one reference to the value, the garbage collector will not collect it (yet). It might collect the value later on, when all the references to it have been eliminated.

The simplest way to do what you want is using a table to contain the references. You can set the values of the table to nil very easily:

Code: Select all

local objects = {}
function object_destroy(objstr)
  objects[objstr] = "whateverthefuckiwant" -- no need to use loadString here
end

...

object_destroy("obj")
When I write def I mean function.
Zephos
Prole
Posts: 18
Joined: Sun Mar 31, 2013 4:53 pm

Re: Problem using the 'SECS' class library

Post by Zephos »

Excellent, that helped a lot. Thanks goes to all of you, and sorry for causing a bit of a fuss.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 5 guests