49
edits
m
→Scope de-resolution
| Line 1: | Line 1: | ||
{{wowlua}} | |||
[[Addons]] in ''World of Warcraft'' share a single execution environment. As a result, all Addons have access to the same global variables. If one Addon creates a global variable named "foo", then all other addons can use (or overwrite) that same variable. This allows for some really useful things to happen; the most frequently used tactic that takes advantage of this feature is [[Hooking functions|hooking]]. Unfortunately, this can also cause some problems in addons. They will conflict if more than one Addon tries to use the same name for a variable. As a result, Addon authors must ensure that their Addons don't conflict by doing one (or more) of the following: | [[Addons]] in ''World of Warcraft'' share a single execution environment. As a result, all Addons have access to the same global variables. If one Addon creates a global variable named "foo", then all other addons can use (or overwrite) that same variable. This allows for some really useful things to happen; the most frequently used tactic that takes advantage of this feature is [[Hooking functions|hooking]]. Unfortunately, this can also cause some problems in addons. They will conflict if more than one Addon tries to use the same name for a variable. As a result, Addon authors must ensure that their Addons don't conflict by doing one (or more) of the following: | ||
#Using assuredly-unique names for variables, such as MyAddon_MyFrame_OnLoad | #Using assuredly-unique names for variables, such as MyAddon_MyFrame_OnLoad | ||
#Making their addons [[Object_Oriented_Programming|object-oriented]] | #Making their addons [[Object_Oriented_Programming|object-oriented]] | ||
#Using variable ''scope'' to the author's advantage. | #Using variable ''scope'' to the author's advantage. | ||
| Line 144: | Line 145: | ||
== Complex scope == | == Complex scope == | ||
Yes, nothing's ever that simple, of course. Above, we have only looked at limiting scope one level at a time. Unfortunately, addons often are complex enough that an author will mix several levels of scope. But how does Lua know which local variable to use? Well, as stated before, Lua uses a rule system called "least visibility." That means, the variable which is "most local" to the current scope will be the one used. Global variables are only used in the event that a local variable does not exist at the current scope. The following block shows a very complex example which isolates the various cases that may occur. | Yes, nothing's ever that simple, of course. Above, we have only looked at limiting scope one level at a time. Unfortunately, addons often are complex enough that an author will mix several levels of scope. But how does Lua know which local variable to use? Well, as stated before, Lua uses a rule system called "least visibility." That means, the variable which is "most local" to the current scope will be the one used. Global variables are only used in the event that a local variable does not exist at the current scope. The following block shows a very complex example which isolates the various cases that may occur. | ||
Note we create the function "p" as a synonym for DEFAULT_CHAT_FRAME:AddMessage because it is a long name to write. More importantly, note that we make this function file-local. Remember, in Lua, functions are variables too. As a result, it is equally possible to make a function local as well. In this case, the function is file-local, meaning that it will be used only within this file, and not be accessible outside of this file. This is often a good idea, especially with very simplistic names such as "p" which other authors may also choose. | Note we create the function "p" as a synonym for DEFAULT_CHAT_FRAME:AddMessage because it is a long name to write. More importantly, note that we make this function file-local. Remember, in Lua, functions are variables too. As a result, it is equally possible to make a function local as well. In this case, the function is file-local, meaning that it will be used only within this file, and not be accessible outside of this file. This is often a good idea, especially with very simplistic names such as "p" which other authors may also choose. | ||
| Line 183: | Line 184: | ||
=== The [[API_getglobal|getglobal]]() function === | === The [[API_getglobal|getglobal]]() function === | ||
''NOTE:'' AS OF PATCH 4.0.1 getlobal() is depreciated and won't work for WOW addons. Use the _G global table methods discussed in the next section. [Also applies to setglobal()] | |||
A function provided by the Lua language is [[API_getglobal|getglobal]](). It does precisely what its name states -- it retrieves a global variable and returns it. To use this function, you pass in a string representation of its name: | A function provided by the Lua language is [[API_getglobal|getglobal]](). It does precisely what its name states -- it retrieves a global variable and returns it. To use this function, you pass in a string representation of its name: | ||
| Line 210: | Line 211: | ||
== Conclusion == | == Conclusion == | ||
Understanding Lua's use of variable scope is vital to understanding the process in which Lua decides which variable to use. Correct use of limited scope will allow your addon to be less likely to conflict with others, and minimize global namespace pollution. | Understanding Lua's use of variable scope is vital to understanding the process in which Lua decides which variable to use. Correct use of limited scope will allow your addon to be less likely to conflict with others, and minimize global namespace pollution. | ||
[[Category:Interface customization]] | [[Category:Interface customization]] | ||
[[Category:Lua functions| Lua Scope]] | [[Category:Lua functions| Lua Scope]] | ||