I'm certain sirinsidiator was just trying to save you some trouble. Maybe we shouldn't have taken the example code literally, but it's really hard to not suggest a more solid design.
The whole debug module (except get/setfenv) is not available in ESO, so this discussion is kinda moot, but I'll go over the code anyway in order to explain the dangers. I assume the code was supposed to be inside libraryFunction, right?
Lua Code:
local addonFunction = debug.getinfo(2).func
local addonObjectName = debug.getupvalues(addonFunction, 1)
-- I think what you meant was:
local name, value = debug.getupvalue(addonFunction, 1)
There're a number of issues with this, though.
upvalues are *local* variables from *outside* scopes that are *used inside* a function.
Because they are locals, looking up _G[name] will give you some completely unrelated object/value/nil.
Second, there's absolutely no guarantee that upvalue #1 will be the calling addon's global table/name.
An example to illustrate:
Lua Code:
function printupvalues()
local caller = debug.getinfo(2)
local i = 1
print(("caller=%s %s"):format(tostring(caller.name), tostring(caller.func)))
while true do
local name, val = debug.getupvalue(caller.func, i)
if name == nil then break end
print(("%4d: name=%s val=%s"):format(i, name, tostring(val)))
i = i + 1
end
end
local a = 1
local b = 2
local c = 3
local function foo(x, y)
local d = 4
local e = 5
local function bar()
b = e + y
printupvalues()
end
a = d + x
printupvalues()
bar()
end
foo's upvalues are: [1]=b, [2]=a -- see how they're in the order they're used in the function, not in the order they're declared!
bar's upvalues are: [1]=b, [2]=e, [3]=y
Notice that `c` is not among either function's upvalues, because it's not used anywhere.
`d` and `x` also aren't upvalues, because they're local in foo, and not used in bar.