Accessing Global Data
Let me begin by stating that I have a MyAddon.xml file and a MyAddon.lua file that are properly aware of and function correctly with each other. Additionally, the xml file defines the UI and the lua file contains needed functions, variables, etc.
My assumption: The names of Frame and FontString entities which are defined in my xml file are available as global variables. The answer to my question is more likely about convention. It seems that within the lua file, after things are loaded, etc., I can access the Frame objects or Fontstring objects directly by name and perform associated functions such as shown below: Code:
in xml Code:
local x = 1; While I have used a FontString as the example of my question, I also assume that these different approachs could be applied to any of the global data that is present at run time. |
Unless you are trying to modify/revive an existing addon in which case you may want to avoid an extensive re-write,
it's best if you use the frame manipulation API both to create and script your frames from lua, without using xml. As to your actual question. #4 is deprecated and should not be used (it means Blizzard can disable it at their convenience since they've warned it's to be phased out) #3 and #2 are equivalent, the difference is only in style as long as the key to the table is a contiguous string. If you had spaces in the name then table["two words"] needs to be used t.two words will not work. #1 makes an implicit lookup in the global table but is otherwise the same as #2 and #3. |
You shouldn't use getglobal(), as it's not only deprecated but is now actually a function-wrapper around _G and is thus actually slower due to the overhead of the function call.
The rest are functionally equivalent, the main difference being syntactic sugar. The only time I use _G["whatever"] is when I am passing in an unknown string (as through a function parameter) or constructing a string; otherwise I use _G.whatever. Edit: Damn it, Dridzt! :) |
The getglobal function is deprecated and shouldn't be used for anything. In terms of performance you're essentially looking up "getglobal" in _G in the first place, then the overhead of a function call plus another lookup in _G for whatever you're trying to access.
I personally just use the variable name when I need to access it with two exceptions. If I have a variable with the same name in a more local scope and need to get to the global I would use _G["var"], and if I need to dynamically create the variable name I could concatenate the key together. _G.var is just syntactic sugar for _G["var"]. |
Quote:
Quote:
To break down the use of each, #1 is best if you need to access just one object directly. #3 would be for dynamically accessing from a list of objects in which you need to apply values to a name in order to construct it. #2 has no practical use. It has nothing more to offer than #1 and uses up more CPU to process for the same result. |
Thanks, all.
Quote:
Thanks, again, guys. |
Right - Blizz prefers to do it that way. But they don't care how you do it. ;)
The only time you really need XML is if you are defining a template to use and a frame-factory type function won't suffice. |
Most people prefer to use Lua over XML. I really don't see any proof either way on long term performance impacts. The idea was that XML was for static UI structures while you'd use Lua for creating dynamic frames. With nearly everything being supported in Lua, pretty much everyone has phased out XML. I think the tree-like XML structure is easier to read and understand in this fashion than lines of linear Lua code. That's just my preference though. It's up to you to decide which way you want to go.
|
Shame we can't write templates using lua. ;)
|
The biggest problem with XML is that it's incredibly verbose, and is just a hassle to write by hand.
Also, using XML, all references must be global, which is another big argument against it. While in Lua you can write: Code:
local f = CreateFrame("Frame") Firstly, you have to give the frame a global name, or you won't be able to access it from your Lua code. Secondly, you have to create an anonymous function to register the event in an OnLoad script, or a global function to be assigned as the OnLoad script. Finally, you either have to make MyAddOn.EventHandler a global function outside of the MyAddOn table (eg. instead of function MyAddOn:EventHandler() ... end you'd need function MyAddOn_EventHandler(MyAddOn) ... end) or double up on function calls by creating another anonymous wrapper function: Code:
<Frame name="SomeGlobalSpam"> |
If you really want XML code to be inaccessible to the global environment, you can clean up after registering a script handler. Furthermore, the following XML structure can be rewritten to use one less stack position in its script handlers.
Code:
<Frame> Code:
<Frame> |
First, Phantom, I assume all references to OnLoad should be replaced with OnUpdate. Otherwise, I am a bit lost.
However. in the first part of your example it is fairly obvious that the OnUpdate function is being passed two arguments - self and elapsed - explicitly. In the rewritten version, where only the function name is declared, do we know what parameters the function will actually receive? |
It receives all the arguments attached to the event.
In your lua file you would just have something like lua Code:
|
Quote:
Quote:
|
Quote:
It's also worth mentioning that OnLoad scripts are unnecessary in Lua, and in fact aren't even supported in Lua; you just declare the frame and then do stuff with it immediately. |
Sorry, guys, I was just looking at the specific code in the example. I was just referring to the mix of tags and functions. I just confused things with my statement about changing the Onload (magenta colored) to OnUpdate (green colored). My bad. I apologize.
Quote:
|
The thinking behind the change to demonstrate with the OnUpdate handler instead was that it runs continually whereas OnLoad runs only once. This was to display the ability to delete the global and show that the handler would still run afterward. I corrected my other post to make the full switch, I thought I had caught all of the OnLoad references, but apparently, there were more. I didn't even notice until now, yesterday was an off day for me. :o
|
Quote:
|
All times are GMT -6. The time now is 11:12 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI