local bit_band = bit.band
... simply creates a local shortcut named "bit_band" that points to the global "bit.band" function. It doesn't replace or change the function in any way. It just makes it faster to access it.
Imagine the global namespace as a book, and yourself as a reader with absolutely no short-term memory. Every time you ask for "bit.band" you have to go through the whole book to find it. Creating a local shortcut -- this is called an "upvalue" -- is like putting a sticky note on the page, so instead of having to look through the thousands of pages in the book (at the moment there are 49,080 objects in my global namespace) you only have to look at the few sticky notes sticking out of the side. Much faster.
Plus, "bit.band" is actually two lookups -- one global lookup to find "bit", and then a table lookup inside "bit" to find "band". So creating the "bit_band" upvalue is even faster in this case.
As far as the game is concerned, looking up a function in the global namespace is exactly the same as looking up a string, table, or other kind of value. It doesn't know what kind of value it is until it's found it. Going back to the book analogy, you know you're looking for a page entitled "COMBATLOG_OBJECT_CONTROL_PLAYER" but until you find the page, you have no idea what information is on that page, or even what
kind of information is on that page.
Now, despite all of this, I wouldn't suggest creating local upvalues for every global thing you access in your addon. Only do it for things you access very frequently, like in an OnUpdate script, or in response to events like CLEU that fire very often. For infrequently accessed globals, the speed doesn't matter, so creating upvalues just adds clutter to your code. Also, upvalues will always point to the original value, so if someone comes along and overwrites the global "bit.band" with a new function, your upvalue will still point to the original function, not the new one. Obviously nobody is (or should be) overwriting "bit.band" but this is another argument against upvaluing everything all the time. Also, there is a limit on the number of locals that can be in scope at once; I don't remember what it is, and you probably won't ever hit it in normal use, but you might if you go wild with upvalues.
That is valid Lua code, but it won't work the way you're imagining. That code will cause your frame to only respond to events if you are outside of a battleground or arena
when the addon first loads, and it won't detect when you enter or leave one and change the script.
If you want to ignore events that occur inside a battleground or arena, you should register for the event that fires when you change zones, and register/unregister CLEU as needed depending on what kind of zone you're in:
Code:
-- Don't register CLEU here!
frame_cleu:RegisterEvent("ZONE_CHANGED_NEW_AREA")
frame_cleu:SetScript("OnEvent", function(self, event, ...)
if event == "ZONE_CHANGED_NEW_AREA" then
local _, instanceType = IsInInstance()
if instanceType == "arena" or instanceType == "pvp" or (instanceType == "none" and GetZonePVPInfo() == "combat") then
-- arena is, obviously, an arena.
-- pvp is a battleground.
-- none with GetZonePVPInfo() == "combat" is an outdoor PvP zone like Wintergrasp.
self:UnregisterEvent("COMBAT_LOG_EVENT_UNFILTERED")
else
-- If not in a pvp zone, register CLEU:
self:RegisterEvent("COMBAT_LOG_EVENT_UNFILTERED")
end
return
end
local timeStamp, event, hideCaster, sourceGUID, sourceName, sourceFlags, sourceRaidFlags, destGUID, destName, destFlags, destRaidFlags, prefixParam1, prefixParam2, dummyparam, suffixParam1, suffixParam2 = ...
-- proceed with CLEU handling
end)