Hi Seerah,
Originally Posted by Seerah
The way the client works is this:
1. Looks at the .toc file to find which files will be used
2. Compiles these Lua/XML files into memory ("loads" them so that the code can be run)
3. Executes (runs) the code in the files, based on load order defined in the .toc
There is no way to skip step 2. But if returning at the start of the file because the player class doesn't match, then the below code does not run (execute) - all that's being used is static memory, the addon doesn't actually do anything. Eventually, iirc, it all gets flushed by the garbage collector because it's not being used. When the addon is disabled, it will not load (compile) at all on the next session - because it's now disabled for that character.
Edit: this is the best way to handle class-specific addons
|
So, even if the addon is set to LoadOnDemand, it still compiles and stays idle after step 2?
Originally Posted by Seerah
This is how libraries (that use LibStub) work:
1. Addon1 loads libraries A, B, and C.
2. Addon2 then loads libraries A, C, and D.
3. LibStub compares the versions of libraries A and C (the duplicates).
--- if the version of the libraries is more recent in Addon2, it allows the code in these libraries to run, and to be what is shared by the two addons
--- it then tosses its references to the code in the older versions of the libraries - the old code is not used/shared by the addons, and it is eventually flushed by the garbage collector
--- if the version of the libraries is more recent in Addon1, the opposite happens
This is very much like your exit out based on class comparison.
|
Yeah, I was aware of how libraries with LibStub work
