Problem using the 'SECS' class library
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Problem using the 'SECS' class library
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.
Re: Problem using the 'SECS' class library
This is actually quite simple:
Replace _G with a table that you're storing your object in.
Code: Select all
test = {}
test.name = 'test'
function test:destroy()
_G[self.name] = nil
end
test:destroy()
print(test)
Last edited by markgo on Fri Apr 19, 2013 11:45 pm, edited 1 time in total.
- 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
You can not do what you want. Let me try to explain this.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:
Now, is there anything to complain about this? In the end, that's all I wanted to know.Code: Select all
function object_destroy(objstr) loadstring(objstr .. " = 'whateverthefuckiwant'")() end ... object_destroy("obj")
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
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.
Re: Problem using the 'SECS' class library
Excellent, that helped a lot. Thanks goes to all of you, and sorry for causing a bit of a fuss.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 5 guests