Multiple file

[Provision]

Hi,

I don't find documentation about that. How can I call function in another file ?

Thank.


This doesn't work :

--file 1 
function TeamFormation_createLAM2Panel ()

end

--file 2
local function TeamFormation_OnAddOnLoad(eventCode, addOnName)
    TeamFormation_createLAM2Panel()
end

[haggen]

The order in which you load the files in the manifest (<add-on name>.txt) matters. So if you define `function TeamFormation_createLAM2Panel` without the `local` scope (as you presented here) in file A and load file A before the file that contains the call `TeamFormation_createLAM2Panel()` it should work just fine.

To make it clear, if your files are like this:

AddOn.txt

## ...

A.lua
B.lua

A.lua

function DoSomething() end

B.lua

local function SomethingElse()
    DoSomething()
end

It'll work. But I'd advise against spilling global functions like that.

[Provision]

I didn't see that I have 2 errors.

I read only the last error. My function was nil because I have an error in my function.

@haggen : Thanks for your reply.

[Randactyl]

I think the more accepted way to do this is by creating a "namespace" table and putting all of your stuff in it.

TeamFormation = TeamFormation or {}
 
local PTF = TeamFormation
 
function PTF.MyFunction()
 
end

That way you can have your globally available functions, but they're all wrapped up in your own little space.

[Justinon]

Originally Posted by Randactyl TeamFormation = TeamFormation or {}

What is the purpose of setting it equal to itself; i.e. checking if the namespace is nil? Is the same effect not achieved by simply typing:

TeamFormation = {}

My first instinct tells me that perhaps the addon information persists after the first time initializing the addon, and therefore makes it more efficient upon the next loading thereafter?

[Randactyl]

It's just safety and is not totally necessary.

Let's say you have two files, main.lua and settings.lua, and that main.lua is listed first in the manifest.

At the top of main.lua you could write

myNamespace = {}

because it is your namespace and this is the first time you're bringing it into the world.

Afterward, in settings.lua, you could either assume myNamespace exists since it should have been created in the first file, or you can chose to set it to a new table if it is still nil for some reason (the previous example).

However, if you were to write

myNamespace = {}

in settings.lua, you would be explicitly discarding anything that was done to the version of myNamespace that was set up in main.lua.

Now, a possible benefit of having the redundancy of

myNamespace = myNamespace or {}

is if somewhere down the line you decide you need to shuffle around the order in which files are loaded. This line could save you an error there if you forget to also shuffle where your namespace is initially declared.

[Sasky]

Originally Posted by Justinon What is the purpose of setting it equal to itself; i.e. checking if the namespace is nil? Is the same effect not achieved by simply typing: TeamFormation = {} My first instinct tells me that perhaps the addon information persists after the first time initializing the addon, and therefore makes it more efficient upon the next loading thereafter?

For a single file, yes it's identical. It's setup like that so that you don't have to worry about what order the files are loaded.

File A:

TF = TF or {}
TF.a = 1

File B:

TF = TF or {}
TF.b = 2

Either file can be loaded first here. Say A is loaded before B. In file A it'll create TF as an empty table. In file B it'll leave TF as it already is. If you're careful about the order that files are read, you don't need this. If you use a separate namespace table per file, you don't need this. However, if you didn't use a similar pattern and loaded the files out-of-order, you'd end up dereferencing NIL:

-- File B
TF.b = 2 -- TF doesn't exist yet
 
-- File A
TF = {}
TF.a = 1

Personally, I find it easier to just use the pattern and ignore file order. Also I tend to load all the class files before the main file, and it fits better with that structure.

[Justinon]

Ah okay, thanks you two, that makes a lot of sense. I guess because I was always careful about the order it never really occured to me that that's the benefit. That's quite useful, and I appreciate the in-depth explanations