Global vars ?

[AlleyKat]

There are no objects in lua, frame is metatable with userdata, where userdata is real frame object, we are not coping userdata, so we are not creating two objects, we are just using object from another instance (another table)

[Phanx]

Yes, but for all practical purposes, they are two different objects in Lua:

local t = {}
local f = CreateFrame("Frame")
print(t == f)

That will print "false" even after all you apply all your pointless hacks. You're completely missing the forest for the trees here.

[AlleyKat]

I said about userdata, not tables

[Phanx]

I was addressing this:

Originally Posted by AlleyKat and now we don't care what table to use, coz they are same

They're not the same. You've just written a bunch of bloated metatable hacks to make them act like they're the same, and this is what I'm saying is absolutely pointless, and a bad programming habit besides.

[AlleyKat]

Originally Posted by Phanx and this is what I'm saying is absolutely pointless, and a bad programming habit besides.

Nope, not pointless, my build-in table now has frame atrrs, and table of original frame works as build-in

local title, M = ...;

local anotherFrame = CreateFrame("Frame", "SomeFrame", M);

another lua file, or addon

local M = SomeFrame:GetParent();

[Phanx]

Clearly you're missing my point, and also the point of this thread -- which is about which variables must be global under the WoW addon system, which nothing you've posted has been related to -- so continuing this conversation is as pointless as tricking a table into behaving like a frame instead of just using a frame. Carry on.

[AlleyKat]

Originally Posted by Phanx as pointless as tricking a table into behaving like a frame instead of just using a frame. Carry on.

Nope, if I want to use already created build-in table as main storage for my addon functions and data

[Fizzlemizz]

Originally Posted by AlleyKat Nope, if I want to use already created build-in table as main storage for my addon functions and data

local title, M = ...;

GLOBAL_REFERNCE_TO_MY_ADDONS_TABLE = M

does not create a seperate copy of the table but "use already created build-in table as main storage for my addon" and is no more global than the frame you created.

[AlleyKat]

hey look, hey

local t, M = ...;
setfenv(1, setmetatable(M, { __index = _G }));

[Fizzlemizz]

I still don't see how this gets you any closer to what I think you think you are gaining from the exersize but I don't think you are.

[Seerah]

Originally Posted by AlleyKat Nope, not pointless, my build-in table now has frame atrrs, and table of original frame works as build-in local title, M = ...; local anotherFrame = CreateFrame("Frame", "SomeFrame", M); another lua file, or addon local M = SomeFrame:GetParent();

I'm really confused by this, too, AlleyKat.

Frames are just special tables. You can store anything you want in there and use it like a regular table. I would do this, since you're creating a frame with a global name anyway:

local frame = CreateFrame("Frame", "MyGlobalFrameName")
 
frame.valueToSave = true
 
frame.initFunc = function()
     --do stuff
end
 
function frame:CallFromModule(var1, var2)
     --do stuff for my module
     return newVar
end

And from another file in my addon (say, a module) or from another addon:

local newVar = MyGlobalFrameName:CallFromModule(var1, var2)

[SDPhantom]

I'm popping in here just to tell AlleyKat, no. Just... no. Bad kat. Bad.
No separating frame userdata from their tables.

All joking aside. From the tests I did on widget objects and their data structure, it's a really bad idea to mess with the userdata placed in the created table. Even though the frame methods receive the table itself and do their own indexing operations to reference the userdata, the callback scripts get their own table reference self from C code that points to the original table created for that frame. With all the hacks needed to make a table transplant work on widget objects, it causes a major performance hit when trying to index the frame from a script. It's much better to just store the frame in your addon table than trying to transplant its innards.

Like this:

local name,addon=...;
addon.Events=CreateFrame("Frame");