m
Move page script moved page UI best practices to WoW:UI best practices without leaving a redirect
(Typo fixing using AWB) |
m (Move page script moved page UI best practices to WoW:UI best practices without leaving a redirect) |
||
| (5 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{uitech}} | ||
With the low barrier to entry, writing mods has become very popular. While this has greatly benefited the WoW community, it does have a dark side. There are idiosyncrasies in both the [[Lua|Lua language]] and the [[World of Warcraft API]] that many authors overlook. This can lead to poorly written programs as measured by performance, memory usage, interference with other addons and the default UI, etc. The techniques gathering on this page will help help addon authors, experienced and otherwise, make the most out of WoW's environment safely and efficiently. | With the low barrier to entry, writing mods has become very popular. While this has greatly benefited the WoW community, it does have a dark side. There are idiosyncrasies in both the [[Lua|Lua language]] and the [[World of Warcraft API]] that many authors overlook. This can lead to poorly written programs as measured by performance, memory usage, interference with other addons and the default UI, etc. The techniques gathering on this page will help help addon authors, experienced and otherwise, make the most out of WoW's environment safely and efficiently. | ||
| Line 11: | Line 11: | ||
One stumbling block for Lua programmers coming from other languages is the fact that all variables are global unless specified otherwise. Many times, the use of global variables is necessary: saved variables are created via the global environment; all API functions and UI frames are in the global namespace. However, globals come at a cost of both performance, and naming conflicts. | One stumbling block for Lua programmers coming from other languages is the fact that all variables are global unless specified otherwise. Many times, the use of global variables is necessary: saved variables are created via the global environment; all API functions and UI frames are in the global namespace. However, globals come at a cost of both performance, and naming conflicts. | ||
Globals | Globals are inefficient to access compared to locals. Whenever a global is accessed, Lua has to call the internal equivalent of getfenv() to figure out where to retrieve the global from. Local variables, on the other hand, are stored on a stack. In code where performance is important (for instance an [[UIHANDLER OnUpdate|OnUpdate handler]]), it's often beneficial to create a local alias to a global function: | ||
local Foo = Foo | local Foo = Foo | ||
| Line 85: | Line 85: | ||
==== Order of Operations ==== | ==== Order of Operations ==== | ||
Lua, like | Lua, like many other programming languages, executes expressions from left to right starting from the innermost parenthesis to the outermost. This allows for un-nesting of IF blocks. | ||
-- This: | -- This: | ||
| Line 99: | Line 99: | ||
DoStuff() | DoStuff() | ||
end | end | ||
Note: There are several programming languages that do not read left to right (eg. Joy, Factor, J and K, etc.). Others - like Haskell - can be used both ways. There are even languages that are multi-dimensional. While many of these are mainly academic, they are not esoteric languages made to be weird, but rather based on recent theories and ideas in computer science. | |||
==== Lazy Coding ==== | ==== Lazy Coding ==== | ||
| Line 107: | Line 109: | ||
DoStuff() | DoStuff() | ||
end | end | ||
if foo | if foo and foo[bar] == 5 then -- will not throw an error | ||
DoStuff() | DoStuff() | ||
end | end | ||
| Line 160: | Line 162: | ||
MyEventHandler() | MyEventHandler() | ||
</OnEvent> | </OnEvent> | ||
Old Lua | Old Lua | ||
function MyEventHandler() | function MyEventHandler() | ||
| Line 174: | Line 175: | ||
MyEventHandler(self, event, ...) | MyEventHandler(self, event, ...) | ||
</OnEvent> | </OnEvent> | ||
New Lua | New Lua | ||
function MyEventHandler(frame, event, firstArg, secondArg) | function MyEventHandler(frame, event, firstArg, secondArg) | ||
| Line 184: | Line 184: | ||
end | end | ||
Even Newer XML | |||
<OnEvent function="MyEventHandler" /> | |||
This has the advantage of resulting in a reference call, without an anonymous code block calling a global function. | |||
==== Lua only ==== | ==== Lua only ==== | ||