funcName = function(p1, p2, ...) instead of function funcName(p1, p2, ...)?

[Duugu]

Today I saw someone doing this:

funcName = function(p1, p2, ...) end

Now I'm asking myself what is this good for? What's the difference to

function funcName(p1, p2, ...) end

[Clamsoda]

Effectively, they are the same. The only difference would be that the former could be stored in a table.

local functionTable = {
    ["function 1"] = function(cats, dogs, horses, ...) print (cats, dogs, horses) end,
    ["function 2"] = function(rabbits, ligers, belugawhales, ...) print (rabbits, ligers, belugawhales) end
}

Edit: I guess another advantage of the former would be that you could change that content of that variable, from a function to something else, if you had a need to do so.

[Duugu]

Originally Posted by Clamsoda ["function 2"] = function(rabbits, ligers, belugawhales, ...) print (rabbits, ligers, belugawhales) [/highlight]

Wow. The super rare and mostly unkown ligers. ;D

Thank you sir.

[semlar]

There is a programmatic difference between them, this post explains it.

I personally use "func = function()" when overwriting an existing function and the latter when defining my own.

[Xrystal]

I tend to use addonTable.FunctionName = function() in my addons rather than function functionName() purely for consistency, benefit wise however I can see addonTable.FunctionName = function useful for functions you want to use throughout your addon but still be 'local' to your addon and not global.


My understanding thus far is :

local function FunctionName() --- Only accessible in the current file
local FunctionName = function() --- Only accessible in the current file

function FunctionName() --- Global to all addons that want to use it
FunctionName = function() --- Global to all addons that want to use it

addonTable.FunctionName = function() ---- Only accessible to files in your addon that have the addonName,addonTable = ... at the top of the lua files.

I am sure there are some overheads in each of these cases so I won't claim to know which is best to use, but I try not to use global functions and variables unless I want the function/variable accessible outside of the addon.

[Phanx]

Originally Posted by Xrystal ... I try not to use global functions and variables unless I want the function/variable accessible outside of the addon.

Even if you do want something to be available outside of the addon, making each item a separate global is not ideal. Instead, create one global table -- usually, your main addon frame/table/AceAddon object/whatever -- and add all the things you want to be "global" to that table, eg.

-- Global addon object:
MyAddon = {} -- or CreateFrame, or AceAddon:New, etc.

-- Local reference to the object, so that all further references
-- to it in this file are faster local lookups, rather than slower global ones:
local MyAddon = MyAddon

-- This function name is NOT in the global namespace itself, but the function
-- can be accessed through the global "MyAddon" table.
function MyAddon:DoStuff()
     print("I'm doing stuff!")
end

-- This variable name is NOT global either, but the variable can also be accessed
-- through the global "MyAddon" table.
MyAddon.someValue = 5

-- This function name IS global, and it shouldn't be!*
function MyAddon_DoStuff()
    print("I'm a slow global. :(")
end

-- This variable name is global, and it shouldn't be!
MyAddon_SomeValue = 5

* There is only one case in which you should ever give an individual function a global name, and that is if you are assigning that function as a script handler for a template defined in XML, and the only reason to define a template in XML is if you are passing it to a secure header. So, chances are very high you will never encounter this case.

[Duugu]

Originally Posted by semlar There is a programmatic difference between them, this post explains it. I personally use "func = function()" when overwriting an existing function and the latter when defining my own.

Thank you.
To sumarize it: there's no advantage of

functionName = function() end

with declaring a function. And there's the disadvantage that a recursive call doesn't work.

[Rainrider]

Recursion can work with both variants and that is explained in the linked post.

[Phanx]

Yes, but with the "var = function" style you have to separately declare "local var" before you can define "var = function" ... why clutter up your code with silly-looking and redundant variable definitions when you can just use "local function var" instead?

Plus, if you are putting your functions in a table and calling them as methods, it's cleaner to write "function tbl:var()" than "tbl.var = function(self)".

[Dridzt]

My excuse is that I do use tables / frames to hold most my functions and my editor of choice gives me a nice sorted function listing on the side.

Using the context.func = function() notation gives me a very nice navigational aid for my code where functions are 'naturally' grouped by context.

[Vlad]

Not sure what I can say to improve this thread.

In general many people like to group up functions in a class-like style. Often modules create a table that contains functions that do specific things on that table only. It's wise to organize your code and avoid global leaking - it's good practice.

[Fizzlemizz]

Can you explain how you would access throught the global "MyAddon" table?

I'm feeling dense, I see addons that:

local _, MyAddon = ...
_G.MyAddon = MyAddon

Isn't that the same as leaving out the
local _, MyAddon = ...

and just having
MyAddon = {}

or am I missing some more magic?

-- This variable name is NOT global either, but the variable can also be accessed -- through the global "MyAddon" table. MyAddon.someValue = 5

[Clamsoda]

Just because something is global doesn't necessarily put it in Blizzard's global table, correct?

_G is just a table in the global scope, if I understand correctly. Declaring a variable globally doesn't inherently put it into _G, that would need to be done manually.

That is my perception, could be wrong of course.

[Xrystal]

Originally Posted by Fizzlemizz Can you explain how you would access throught the global "MyAddon" table? I'm feeling dense, I see addons that: local _, MyAddon = ... _G.MyAddon = MyAddon Isn't that the same as leaving out the local _, MyAddon = ... and just having MyAddon = {} or am I missing some more magic?

if they hadn't added it to the _G table then it would only be global to your addon, useful for splitting up large files. Adding it to _G table I expect would mean it is now accessible by other addons, of course it would override a value already in existence with the same name in that table.

[Fizzlemizz]

Maybe my perception is messed from having changed a ton of GetGlobal calls to _G when I started on lua so my assumtion has been that _G = global global . It would be nice and useful to be set correct.

Originally Posted by Clamsoda Just because something is global doesn't necessarily put it in Blizzard's global table, correct?

[SDPhantom]

Originally Posted by Fizzlemizz Maybe my perception is messed from having changed a ton of GetGlobal calls to _G when I started on lua so my assumtion has been that _G = global global . It would be nice and useful to be set correct.

Actually, _G is the same as _G._G, it's a circular reference and completely unnecessary. This also means _G.MyVar is the exact same as referencing MyVar directly as long as you don't have a local definition for the variable.



The only possible use of the _G table is to reference a global by the contents of another variable.

local index="SomeVar";
print(_G[index]);

This will print out the contents of the global SomeVar.

[Fizzlemizz]

I understand that, it's the storage of global/not global I'm trying to figure.

Is
function MyFunction()
...
end

essentially the same as
local function MyFunction()
...
end
_G.MyFunction = MyFunction()

or does the first get stored globally and the second in a seperate "container" within the global space?

[Seerah]

It is also useful when concatenating two strings together to find the global object. ie,

for i = 1, 12 do
     _G["ActionButton"..i]:DoSomething()
end

@Clamsoda: Anything left global is going to be in the global namespace. _G is everything in the global namespace. You don't need to manually put it there.


As Xrystal said, the contents of the vararg (...) passed to your addon are not real globals. Their scope is limited to your addon only and all the files it contains. If an author chooses to add their addon table to _G, then it is accessible to any addon as it is in the global namespace at that point.

@Fizzlemizz: The getglobal() function was just a wrapper to look something up in the _G table.

function getglobal(thing)
     return _G[thing]
end

Because it was just this thin wrapper, it was deprecated and (eventually) removed from the API. A table lookup is cheaper than a function call (especially one that just does that table lookup).


Lastly, as SDPhantom pointed out, doing _G.MyVar is pointless, as you can just reference MyVar itself, unless you want to specifially call a copy of MyVar that is global rather than a local copy (which may have a different value).

myVar = "apple"
local myVar = "banana"
print(myVar) --> "banana"
print(_G.myVar) --> "apple"

[Seerah]

To your second post, Fizzlemizz, those are functions and not tables. That would not work the same way, as when you save a table to a different variable name (or, local vs global variable) a pointer is created to the same table that is in memory.

local myTable = {}
_G.myTable = myTable
print(myTable) --> table:009238 (reference/index to table in memory)
print(_G.myTable) --> table:009238 (same table! just using a different variable for access)

Making a change to the table will be accessible from either way you access it. (Think front and back doors on your house. You can paint the kitchen yellow, and it will still be yellow no matter which door you come in from.) If you want to actually copy the table and have two different tables with the same contents, you have to do that manually.

Functions don't work the same way.

local function myFunc() end
_G.myFunc = myFunc
print(myFunc) --> function:093hj1k
print(_G.myFunc) --> function:1lk098a

Functions get "copied", so you now have two separate functions independent of one another. It's just like doing

varA = "apple"
varB = varA
varA = "banana"
print(varA) --> "banana" (because we changed it on line 3)
print(varB) --> "apple" (because varA still was "apple" when assigning varB on line 2)

[Fizzlemizz]

Thank you Seerah et. al.

For the final piece of the puzzle, is Clamsoda's assertion (belief) correct that

"_G is just a table in the global scope, "

and that is where you store (copy, place) variables and functions you want make accessible to other addons (directories under \Interface\Addons).

I've got some ancient addons that I'm certain are rank offenders in cluttering up the global scope and I would very much like to make them better community players.