WoWInterface - _G for local variables

WoWInterface (https://www.wowinterface.com/forums/index.php)

- Lua/XML Help (https://www.wowinterface.com/forums/forumdisplay.php?f=16)

- - _G for local variables (https://www.wowinterface.com/forums/showthread.php?t=41779)

_G for local variables

After searching and trying almost an hour to find a way to access local variables with dynamic names (and facepalming when the most simple solution sprang to my mind...), I'm still wondering: is there a way, analogue to _G for global variables, to access local variables?

lua Code:

-- the _G way
globalvar1 = "foo"
globalvar2 = "bar"
for i=1, 2 do
  _G["globalvar"..i] -- do sth with it
end
 
-- trying it local
local localvar1 = "foo"
local localvar2 = "bar"
for i=1, 2 do
  ?? -- how could those be accessed?
end
 
-- my workaround
local localvar = {
  "foo",
  "bar"
}
for i=1, 2 do
  localvar[i] -- do sth with it
end

Hmm, correct me if I'm wrong but couldn't you just imitate the _G with a local version, since as far as I understand, _G is just a table.

So:

lua Code:

local _L = {}
 
_L['localvar1'] = 'foo'
_L['localvar2'] = 'bar'
 
for i=1, 2 do
    _L["localvar"..i] -- do sth with it
end

Not as neat assignment though...

I think what you're trying to say, is there a different way of getting the global variable without using this?

Lua Code:

_G["varname"]

In the usage you're describing, no.

Offtopic, what's the tag for showing lua-code like that? With syntax highlighting and all.

Quote:

Originally Posted by ballagarba (Post 247102)

Offtopic, what's the tag for showing lua-code like that? With syntax highlighting and all.

It's the same as 'code', but instead of 'code' it's 'lua'.

^ WRONG

use '[' highlight=lua ']' closed with '[' /highlight ']'.

As for a true Lua global, there's no way to define or read dynamic locals. However as you've demonstrated, you may define a single local table that holds additional data as key/value pairs. I would advise against this unless absolutely necessary as table entries consume more resources than locals themselves. I follow the simple rule, tables are only for list/structure data, everything else is to stay in locals.

Quote:

Originally Posted by ballagarba (Post 247100)

Hmm, correct me if I'm wrong but couldn't you just imitate the _G with a local version, since as far as I understand, _G is just a table.

Effectively that's what I've done in my workaround (just different variable names), seems you got that idea faster than I did :D

Quote:

Originally Posted by suicidalkatt (Post 247101)

I think what you're trying to say, is there a different way of getting the global variable without using this?

Lua Code:

_G["varname"]

In the usage you're describing, no.

No, I was looking for a way to get a local variable, similar to how you use _G to get a global variable.

Quote:

Originally Posted by SDPhantom (Post 247104)

So, it'd be faster and more efficient to hardcode everything that needs to be done for each local, instead of putting them into a table and iterating over it?

Quote:

Originally Posted by SaraFdS (Post 247111)

So, it'd be faster and more efficient to hardcode everything that needs to be done for each local, instead of putting them into a table and iterating over it?

If the data is unrelated to each other, yes. I don't know the code that you're trying to use this method for, so I can't state any more specific ways to make your code efficient. As for any rule of thumb, there can be and often are exceptions.

If you need such a construct for local variables, you're probably structuring your code incorrectly; scoping is a logical tool, not something to be avoided.

local addonName, _L = ...

Could then use _L table for local addon storage, accessible across files, but shouldn't be used for standard data access like OnUpdate loop constantly accessing the table _L.data={} at certain index would take more resources than having a local data = ... where the data is directly stored in the variable local to that file. Table within table is slower than just one table.

Anyway, probably not useful info.

Quote:

Originally Posted by SDPhantom (Post 247112)

I'm creating two FontStrings to display timers. The event that updates them fires ~every second. To not overwrite them if nothing changed, I'm caching their state, also in two local vars.

lua Code:

local BGtext = {
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal"),
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal")
}
local laststatus = {"",""}
BGtext[1]:SetPoint("RIGHT",MiniMapBattlefieldFrame,"LEFT")
BGtext[2]:SetPoint("TOPRIGHT",BGtext[1],"BOTTOMRIGHT")
MiniMapBattlefieldFrame:RegisterEvent("UPDATE_BATTLEFIELD_STATUS")
MiniMapBattlefieldFrame:SetScript("OnEvent",function(s,e,a)
    if e == "UPDATE_BATTLEFIELD_STATUS" then
        for i=1,2 do
            local status, map = GetBattlefieldStatus(i)
            if status == "queued" then
                BGtext[i]:SetText(MySecondsToTime((GetBattlefieldEstimatedWaitTime(i)-GetBattlefieldTimeWaited(i))/1000))
            else
                if status ~= laststatus[i] then
                    laststatus[i] = status
                    if status == "confirm" then
                        BGtext[i]:SetText(map)
                    else
                        BGtext[i]:SetText("")
                    end
                end
            end
        end
    end
end)

Quote:

Originally Posted by Torhal (Post 247118)

If you need such a construct for local variables, you're probably structuring your code incorrectly; scoping is a logical tool, not something to be avoided.

The scope ain't a problem, it's just the fact, that I cannot access the variables the way I need/want to. I could have avoided this problem by simply declaring all 4 vars as globals, but that would have been the wrong way as far as I know.

Quote:

Originally Posted by SaraFdS (Post 247133)

I'm creating two FontStrings to display timers. The event that updates them fires ~every second. To not overwrite them if nothing changed, I'm caching their state, also in two local vars.

lua Code:

local BGtext = {
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal"),
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal")
}
local laststatus = {"",""}
BGtext[1]:SetPoint("RIGHT",MiniMapBattlefieldFrame,"LEFT")
BGtext[2]:SetPoint("TOPRIGHT",BGtext[1],"BOTTOMRIGHT")
MiniMapBattlefieldFrame:RegisterEvent("UPDATE_BATTLEFIELD_STATUS")
MiniMapBattlefieldFrame:SetScript("OnEvent",function(s,e,a)
    if e == "UPDATE_BATTLEFIELD_STATUS" then
        for i=1,2 do
            local status, map = GetBattlefieldStatus(i)
            if status == "queued" then
                BGtext[i]:SetText(MySecondsToTime((GetBattlefieldEstimatedWaitTime(i)-GetBattlefieldTimeWaited(i))/1000))
            else
                if status ~= laststatus[i] then
                    laststatus[i] = status
                    if status == "confirm" then
                        BGtext[i]:SetText(map)
                    else
                        BGtext[i]:SetText("")
                    end
                end
            end
        end
    end
end)

I would suggest not queueing the status. I don't know the exact CPU impact between caching/contitional checking and just doing a flat out call to change the text, but my instinct would be to just let the code run through. You can also clean things up by running an iterator through your FontString object table.

lua Code:

local BGtext = {
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal");
    MiniMapBattlefieldFrame:CreateFontString(nil,nil,"GameFontNormal");
};
 
BGtext[1]:SetPoint("RIGHT",MiniMapBattlefieldFrame,"LEFT");
BGtext[2]:SetPoint("TOPRIGHT",BGtext[1],"BOTTOMRIGHT");
 
MiniMapBattlefieldFrame:RegisterEvent("UPDATE_BATTLEFIELD_STATUS");
MiniMapBattlefieldFrame:SetScript("OnEvent",function(s,e,a)
    if e=="UPDATE_BATTLEFIELD_STATUS" then
        for i,j in ipairs(BGtext) do
            local status,map=GetBattlefieldStatus(i);
            if status=="queued" then
                j:SetText(MySecondsToTime((GetBattlefieldEstimatedWaitTime(i)-GetBattlefieldTimeWaited(i))/1000));
            elseif status == "confirm" then
                j:SetText(map);
            else
                j:SetText("");
            end
        end
    end
end);