Global vars ?
Quote:
I opened this new post because I like to discuss about this a little bit more if possible.... Is there a reason to use a variable as NON LOCAL ? For example ... another addon of mine: Aggromon uses some saved variables for the configuration option. These are defined in the .toc file: Lua Code:
and in the addon I have: Lua Code:
I used them as non local, but the names should be fine to not break any others things in the UI. The question is :-) Is it fine or I should define them as local even if I am exporting outside the addon ... Thanks again to all of you. P.s Checking better I have also this one :-) Lua Code:
|
Quote:
Slash commands must be global, else the user won't be able to use them. |
Quote:
|
Most variables you create and use in the course of writing an addon should remain local. There are very few situations where a global variable is necessary or desirable. You should get to know what those situations are, and avoid using globals in any other situations.
Saved variables are necessarily global. If your addon uses more than ~3 saved variables, as in the example you posted, it's probably better to do as Resike said and switch over to saving a single table with all those things inside it: Code:
## SavedVariables: AggroMonDB Code:
AggroMonDB = { Code:
CreateFrame("Frame", "MyFrame", UIParent) (a) secure objects like action buttons, (b) objects that inherit from a Blizzard templates like ActionButtonTemplate that expect a name, and (c) your addon's main frame object. For everything else, just pass nil where the Create* API accepts a name, and use local references: Code:
local frame = CreateFrame("Frame", nil, UIParent) Slash commands are also necessarily global: Code:
SLASH_MYADDON1 = "/myaddon" Code:
BINDING_HEADER_MYADDON = "MyAddon" Quote:
1. The values passed to your addon files are not globals. They're not even assigned to variables at all unless you assign them to variables yourself. 2. Your example is backwards; the first value passed into each file is the addon's folder/TOC name, and the second is a table. There's also no reason whatsoever to assign the value to "n" and then assign it to "ADDON_NAME" immediately afterwards, and your example is putting that "ADDON_NAME" in the global namespace, which is a horrible idea. Code:
local ADDON_NAME, privateTable = ... privateTable is a table. It starts out empty, but you can add whatever you want to it, and those contents are then available in all of your addon's files, since all references point to the same table object. |
One other reason to use global scope variables is if your AddOn creates APIs that a separate AddOn might use. For example, HandyNotes has several globals, which is how any plugins gain access.
TomTom has some global APIs that other AddOns can use to add waypoints to TomTom. However, in most cases it is best to create AddOns as being as much self-enclosed as possible. |
You're confusing methods with global variables. There's only one global here:
Code:
function TomTom:SetClosestWaypoint(...) Code:
TomTom = { |
Quote:
Quote:
Code:
local t, n = ...; Code:
local title, M = ...; |
Quote:
|
Quote:
Code:
local title, M = ...; and frame with addon's name tag now acting like build-in table, that acting like frame and now my build-in table has frame methods |
Quote:
Code:
local title, M = ...; |
Ah, my RegisterEvent function not from frame
|
Quote:
|
Quote:
|
Quote:
|
Quote:
|
In my way I can access to my frame via
Code:
local title, M = ...; Code:
local title = ...; |
Quote:
in frame case we redirect all get and set notfound operations to build-in in build-in we adding frame api and now we don't care what table to use, coz they are same |
Btw my method is used only to extend build-in table, not to make it global, makes it global - side affect of frame, and I don't recommend use it only to make your table global
|
Quote:
Code:
local title, M = ...; |
Quote:
Quote:
|
All times are GMT -6. The time now is 05:53 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI