Return outside a function?
Looking at the basic example for using LibStub (http://www.wowace.com/addons/libstub/#w_basic-example), I've encountered a return statement that I don't quite understand, as it is outside of any function.
Lua Code:
This leads me to think that addons are run as functions, and this return statement will terminate the addon. I wrote a little test to confirm this theory: load order: file1, file2 file1: Lua Code:
file2: Lua Code:
After running this code, only "zero" gets output, confirming my suspicion. However, I'm not sure if my suspicion covers everything here and the addon simply gets terminated, or there are implications for using this that I don't understand. I would appreciate if anyone could elaborate, since my googling haven't been helpful. |
This isn't restricted to just WoW. The entire file, known as the main chunk, is seen by Lua as a function. After compiling into its own binary format, Lua immediately runs the function generated. This is for each addon file, so if you need to stop your addon from loading, you need to put checks like this in all of the .lua files.
There are some restrictions to using return that follow the same rules as if they were in a function. They are required to be at the end of a scope. Note chunks are blocks of code in which locals defined within are isolated. This includes function definitions, conditional blocks, and loops. You may also force a chunk to be defined by using the do ... end block. |
Thanks for the info. =)
Quote:
EDIT: Ehh... disregard this. Seems I made a typo in the filename in my .toc |
Quote:
Code:
local ADDON_NAME, private_table = ... |
Let's break this down, line by line.
Code:
local lib = LibStub:NewLibrary("MyLibrary-1.0", 1) It is author preference to start the MINOR at 1; I've seen authors start at 90000 + tonumber(repository commit number [ie:// v46]) which would become 90046. Both methods are fine. As Phanx said, this would be equivalent to Code:
local ADDON_NAME, private_table = ... If LibStub rejects lib, it is usually because a library with that MAJOR name and MINOR version or higher already exists in LibStub's internal table structure. Code:
if not lib then Presuming alphabetical load order (not a guarantee, btw), if MyAddOn loads SomeLib (MINOR 1), it will stay in LibStub's structure. Then YourAddOn loads SomeLib (MINOR 2), and SomeLib (MINOR 1) gets unloaded. If both MINOR versions of SomeLib are the same (1 == 1) then when YourAddOn loads SomeLib, LibStub reports back "already loaded and here it is". Keep in mind that the only reason to load two version of the same library is because they are not truly the same; there has been breaking changes between versions. In that case, the MAJOR is incremented by the author, and by convention, the MINOR would be reset by the author. The original version of the library could continue wholly on its own, completely independently. "SomeLib-1.0" =/= "SomeLib-1.1" =/= "SomeLib-2.0". All these MAJORs would be loaded by LibStub concurrently, and each AddOn that needs a particular version would work fine. When such a case exists (LibDataBroker-1.0 and LibDataBroker-1.1 for example) it is highly recommended that the author of MyAddOn update their code to use the newer version. Hopefully this helps! |
Great to know the conventions, thanks for the help!
|
Quote:
|
This has gotten derailed a bit. The OP was posting a question about how return could be used to stop execution of a Lua file. Now it's gotten into how LibStub works.
|
Quote:
Also using a conditional that always evaluates as true can be replaced with the following code for faster execution. Code:
do Note whitespace is irrelevant to Lua, so the previous code could be written as this to make it better to read. Code:
do return end |
All times are GMT -6. The time now is 06:12 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI