WoW:Lua variable scoping - Revision history

Move page script: Move page script moved page Lua variable scoping to WoW:Lua variable scoping without leaving a redirect

2023-08-15T04:48:35Z

Move page script moved page Lua variable scoping to Lua variable scoping without leaving a redirect

← Older revision

Revision as of 04:48, 15 August 2023

Bear at 17:38, 19 March 2022

2022-03-19T17:38:44Z

← Older revision		Revision as of 17:38, 19 March 2022
Line 1:		Line 1:
	{{wowlua}}		{{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]]

Bear: /* Scope de-resolution */

2013-10-01T02:54:42Z

Scope de-resolution

WoWWiki>Zortingo: /* The getglobal() function */

2010-11-07T23:22:53Z

The getglobal() function

← Older revision		Revision as of 23:22, 7 November 2010
Line 182:		Line 182:

	=== 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:

WoWWiki>Starlightblunder: /* Conclusion */ un-h1

2009-06-02T12:04:59Z

Conclusion: un-h1

← Older revision		Revision as of 12:04, 2 June 2009
Line 205:		Line 205:
	This can allow authors to write much more compact code which performs the same operation, though it may be less readable. As always, use the appropriate tool for the situation to help maintain readability.		This can allow authors to write much more compact code which performs the same operation, though it may be less readable. As always, use the appropriate tool for the situation to help maintain readability.

	= 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]]

WoWWiki>Sververda: /* Function-local variables */

2009-02-27T13:29:20Z

Function-local variables

← Older revision		Revision as of 13:29, 27 February 2009
Line 98:		Line 98:

	function foo(bar, baz)		function foo(bar, baz)
	DEFAULT_CHAT_FRAME:AddMessage(tostring(bar)..", "..tostring(baz));		local n = bar + baz;
			DEFAULT_CHAT_FRAME:AddMessage(tostring(bar).." + "..tostring(baz).." = "..tostring(n));
	end		end
	foo(1,2) -- Prints 1, 2		foo(1,2) -- Prints 1 + 2 = 3
	DEFAULT_CHAT_FRAME:AddMessage(tostring(bar)..", "..tostring(baz)); -- Prints nil, nil (out of scope)		DEFAULT_CHAT_FRAME:AddMessage(tostring(bar).." + "..tostring(baz).." = "..tostring(n)); -- Prints nil + nil = nil (out of scope)

			Function-local parameter variables are not directly declared by the author (though they are essentially created by the author, as the author created the function), but they operate in the same manner. They are still local variables and should be treated as such. Besides the parameters the author can still explicitly declare local variables inside the function that are function-local variables.

	Function-local variables are not directly declared by the author (though they are essentially created by the author, as the author created the function), but they operate in the same manner. They are still local variables and should be treated as such.

	=== Block-local variables ===		=== Block-local variables ===
	Block-local variables, like their name suggests, are variables which are accessible only within the code block in which they are defined. These are often used for simplistic names which only need to be quickly accessed within that function and nowhere else. These are often counters or temporary variables which are no longer necessary once the function returns. Take the following function, for example, which adds two numbers together:		Block-local variables, like their name suggests, are variables which are accessible only within the code block in which they are defined. These are often used for simplistic names which only need to be quickly accessed within that function and nowhere else. These are often counters or temporary variables which are no longer necessary once the function returns. Take the following function, for example, which adds two numbers together:

WoWWiki>Rolandius: Corrected spelling/grammar

2009-02-27T13:20:44Z

Corrected spelling/grammar

← Older revision		Revision as of 13:20, 27 February 2009
Line 1:		Line 1:
	[[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.

	== What is ~~Scope~~? ==		== What is scope? ==
	No, it's not just a mouthwash. A variable's ''scope'' defines how visible it is to the rest of the program. The feature exists in most high-level languages, and [[Lua]] is no exception.		No, it's not just a mouthwash. A variable's ''scope'' defines how visible it is to the rest of the program. The feature exists in most high-level languages and [[Lua]] is no exception.

	Variables can exist in two forms: "global," or "local." A global variable is accessible to everything and is not limited. This is the default functionality in Lua. This is unlike many other languages, such as PHP and C, where a variable is always local unless declared global. This difference is important to note. A global variable is not limited to its file, function, or code block:		Variables can exist in two forms: "global" or "local." A global variable is accessible to everything and is not limited. This is the default functionality in Lua. This is unlike many other languages, such as PHP and C, where a variable is always local unless declared global. This difference is important to note. A global variable is not limited to its file, function, or code block:

	foo = 1;		foo = 1;
Line 50:		Line 50:
	Whenever writing addons, it is important to understand the concept of a variable's scope, because it tells the author where a variable is defined (and in some cases, which variable will be used). In general, it is best, in most programming languages, to keep a limited-scope approach, that is, to minimize variable visibility. If a variable does not need to be accessed by other addons and files, it should be kept local. Excessive, unnecessary use of global variables is called "polluting the global namespace" and is often looked upon as a messy or sloppy programming practice.		Whenever writing addons, it is important to understand the concept of a variable's scope, because it tells the author where a variable is defined (and in some cases, which variable will be used). In general, it is best, in most programming languages, to keep a limited-scope approach, that is, to minimize variable visibility. If a variable does not need to be accessed by other addons and files, it should be kept local. Excessive, unnecessary use of global variables is called "polluting the global namespace" and is often looked upon as a messy or sloppy programming practice.

	=== Out ~~Of Scope~~ and ~~Garbage Collection~~ ===		=== Out of scope and garbage collection ===
	A variable is said to have gone "out of scope" when it is no longer accessible by the currently executing code block. If a variable is out of scope, it is eligible for garbage collection. If no accessible references exist to the variable anymore, the variable will be garbage collected at some point in the future. Take note that this implies that global variables will never be garbage collected unless they are overwritten because they never go out of scope.		A variable is said to have gone "out of scope" when it is no longer accessible by the currently executing code block. If a variable is out of scope, it is eligible for garbage collection. If no accessible references exist to the variable anymore, the variable will be garbage collected at some point in the future. Take note that this implies that global variables will never be garbage collected unless they are overwritten because they never go out of scope.

	== Local ~~Variables~~ ==		== Local variables ==
	Local variables exist in many forms. What's important to remember is that local variables exist in a minimal-scope context. That is, they only exist for the block in which they are defined. Although they are all declared in the same fashion, local variables can effectively be split into three types. These types are listed below, ordered from most visible to least visible:		Local variables exist in many forms. What's important to remember is that local variables exist in a minimal-scope context. That is, they only exist for the block in which they are defined. Although they are all declared in the same fashion, local variables can effectively be split into three types. These types are listed below, ordered from most visible to least visible:
	#File-local variables		#File-local variables
Line 59:		Line 59:
	#Block-local variables		#Block-local variables

	=== File-local ~~Variables~~ ===		=== File-local variables ===
	File-local variables, as their name suggests, are local to the file in which they are declared. To be accessible throughout the entire file, they must be declared outside of any function or code blocks, otherwise they will become function-local or block-local, respectively. These variables are not accessible in any other file. Addons can make extensive use of these types of local variables because it ensures that variable names will not conflict with other addons. These types of local variables are especially effective for variables which may need to be accessed throughout the file in which they are declared (often times, this is the entire addon), but never needed outside of that file. This can allow an author to use very simple, easy-to-remember variable names, without worrying about conflicting with other addons. Take the following examples:		File-local variables, as their name suggests, are local to the file in which they are declared. To be accessible throughout the entire file, they must be declared outside of any function or code blocks, otherwise they will become function-local or block-local, respectively. These variables are not accessible in any other file. Addons can make extensive use of these types of local variables because it ensures that variable names will not conflict with other addons. These types of local variables are especially effective for variables which may need to be accessed throughout the file in which they are declared (often times, this is the entire addon), but never needed outside of that file. This can allow an author to use very simple, easy-to-remember variable names, without worrying about conflicting with other addons. Take the following examples:

Line 88:		Line 88:
	Now, note that in this example, no matter which function we call, we will always see "MyAddon2" output. This is because MyAddon2.lua was loaded second, and overwrote MyAddon.lua's name. They both use the same global scope, and as such, they are the same variable. Thus, using file-local variables for those variables which only the addon is concerned about is always considered a best-practice, as it limits visibility and overall prevents conflicts. This practice allows you to use much simpler names without needing to worry about whether or not the same name will be used by another addon.		Now, note that in this example, no matter which function we call, we will always see "MyAddon2" output. This is because MyAddon2.lua was loaded second, and overwrote MyAddon.lua's name. They both use the same global scope, and as such, they are the same variable. Thus, using file-local variables for those variables which only the addon is concerned about is always considered a best-practice, as it limits visibility and overall prevents conflicts. This practice allows you to use much simpler names without needing to worry about whether or not the same name will be used by another addon.

	=== Function-local ~~Variables~~ ===		=== Function-local variables ===
	Function-local variables are not declared, but are still local variables nonetheless. They are created when a function is called, and are the parameters of a function. Take the following example function:		Function-local variables are not declared, but are still local variables nonetheless. They are created when a function is called, and are the parameters of a function. Take the following example function:

Line 105:		Line 105:
	Function-local variables are not directly declared by the author (though they are essentially created by the author, as the author created the function), but they operate in the same manner. They are still local variables and should be treated as such.		Function-local variables are not directly declared by the author (though they are essentially created by the author, as the author created the function), but they operate in the same manner. They are still local variables and should be treated as such.

			=== Block-local variables ===
	=== Block-local ~~Variables~~ ===
	Block-local variables, like their name suggests, are variables which are accessible only within the code block in which they are defined. These are often used for simplistic names which only need to be quickly accessed within that function and nowhere else. These are often counters or temporary variables which are no longer necessary once the function returns. Take the following function, for example, which adds two numbers together:		Block-local variables, like their name suggests, are variables which are accessible only within the code block in which they are defined. These are often used for simplistic names which only need to be quickly accessed within that function and nowhere else. These are often counters or temporary variables which are no longer necessary once the function returns. Take the following function, for example, which adds two numbers together:

Line 143:		Line 142:
	This could be useful in OnUpdate scripts that must use a frame/table each time it's executed, which is horribly inefficient.		This could be useful in OnUpdate scripts that must use a frame/table each time it's executed, which is horribly inefficient.

	== 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.

Line 176:		Line 175:
	Now, is it a best-practice to use the same variable name for every variable you get your hands on? Most certainly not, but it does provide some extra functionality that can be useful. In general, you should avoid using names that are the same, especially as much as the above function foo(), where it can become very difficult to determine which version of "n" you are using, but it is useful on occasion to be able to localize variables. Always remember, however, that the most local variable will always be used, where possible. Global variables are a last resort.		Now, is it a best-practice to use the same variable name for every variable you get your hands on? Most certainly not, but it does provide some extra functionality that can be useful. In general, you should avoid using names that are the same, especially as much as the above function foo(), where it can become very difficult to determine which version of "n" you are using, but it is useful on occasion to be able to localize variables. Always remember, however, that the most local variable will always be used, where possible. Global variables are a last resort.

	== Scope De-~~Resolution~~ ==		== Scope de-resolution ==
	Sometimes it is necessary to use a global version of a variable instead of a local copy which may exist. Luckily, Lua provides a mechanism to do this. In general, it won't be necessary if you follow programming best-practices, but occasionally it can be useful to use. Lua provides two methods to obtain a global variable:		Sometimes it is necessary to use a global version of a variable instead of a local copy which may exist. Luckily, Lua provides a mechanism to do this. In general, it won't be necessary if you follow programming best-practices, but occasionally it can be useful to use. Lua provides two methods to obtain a global variable:
	#The [[API_getglobal\|getglobal]]() function		#The [[API_getglobal\|getglobal]]() function
Line 198:		Line 197:

	=== The _G Table ===		=== The _G Table ===
	Lua also creates and maintains a table defined by the language which contains all global variables. This table is named _G. You access it similarly to getglobal() -- its keys are the string representations of variable names. As such, the same block exemplified in the previous section could be rewritten thusly, with the exact same result:		Lua also creates and maintains a table defined by the language which contains all global variables. This table is named _G. You access it similarly to getglobal() — its keys are the string representations of variable names. As such, the same block exemplified in the previous section could be rewritten thusly, with the exact same result:

	local global_n = getglobal("n"); -- These two lines		local global_n = getglobal("n"); -- These two lines

WoWWiki>Sververda at 13:09, 27 February 2009

2009-02-27T13:09:57Z

← Older revision		Revision as of 13:09, 27 February 2009
Line 1:		Line 1:
	[[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 ~~they both try~~ 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]]

WoWWiki>Starlightblunder: tweak lead-in links.

2009-02-12T01:16:11Z

tweak lead-in links.

← Older revision		Revision as of 01:16, 12 February 2009
Line 1:		Line 1:
	[[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 [[~~HOWTO:_Hook_a_Function~~\|hooking]]. Unfortunately, this can also cause some problems in addons. They will conflict if they both try 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 they both try 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]]

WoWWiki>Charibot: catfix

2008-07-07T18:37:30Z

catfix

← Older revision		Revision as of 18:37, 7 July 2008
Line 208:		Line 208:
	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]]

← Older revision		Revision as of 02:54, 1 October 2013
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()]		''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]]