LibCoreAPI

[Slakah]

Originally Posted by Cralor I don't know much about metatables, but trusting your knowledge with them, the above does print "Frames share same metatable".

nah I was being special :P. This would work.

if getmetatable(CreateFrame("Frame")).__index == getmetatable(CreateFrame("Frame")).__index then
	print("Frames share same metatable")
else
	print("Slakah fails and is special")
end

[nightcracker]

Originally Posted by Slakah nah I was being special :P. This would work. if getmetatable(CreateFrame("Frame")).__index == getmetatable(CreateFrame("Frame")).__index then print("Frames share same metatable") else print("Slakah fails and is special") end

THAT works, FRAMES have shared metatables, but you seam to forget:

Animation
AnimationGroup
Button
CheckButton
ColorSelect
ControlPoint
Cooldown
DressUpModel
EditBox
Font
FontInstance
FontString
GameTooltip
LayeredRegion
MessageFrame
Minimap
Model
MovieFrame
ParentedObject
PlayerModel
QuestPOIFrame
ScriptObject
ScrollFrame
ScrollingMessageFrame
SimpleHTML
Slider
StatusBar
TabardModel
Texture

So:

local f = CreateFrame("Frame")
local tex = f:CreateTexture()
print(getmetatable(f).__index==getmetatable(tex).__index)

RESULT: False.

There is an other difference between this and OmniCC, OmniCC securehooks the "SetCooldown" function. Once they got their hands on the setcooldown function it works for ALL metatables, because metatables do have shared functions. But if you add a function to "Frame" it's not automaticly added to "texture".

[Slakah]

Originally Posted by nightcracker There is an other difference between this and OmniCC, OmniCC securehooks the "SetCooldown" function. Once they got their hands on the setcooldown function it works for ALL metatables, because metatables do have shared functions. But if you add a function to "Frame" it's not automaticly added to "texture".

I never suggested that frames of different types have the same metatable:

You don't need to at all, all frames of the same type share the same metatable

Anyway looping through a few frame types would be a lot easier than going through _G.

[nightcracker]

Originally Posted by Slakah I never suggested that frames of different types have the same metatable: Anyway looping through a few frame types would be a lot easier than going through _G.

Finally the answer :P

Originally Posted by nightcracker Should I loop _G like this for gathering all metatables, or should I run this once, write the names down, and always use these(subject to changes/deletion of frames by blizzard)? local metatables = {} for key, val in pairs(_G) do     if type(val)=="table" and val.GetObjectType then         obj = val:GetObjectType()         if not metatables[obj] then             metatables[obj] = getmetatable(val).__index         end     end end

[haste]

Oh joy. Yet another library putting semi-arbitrary functions into on bloated scope while modifying the global environment for everyone. I'm guessing AlarLib was starting to feel lonely...

That out of the way; What your doing is really just a bad idea. Your plan to modify the metatable for _all_ objects is just asking for collisions to happen. The chance of it happening increases with every reference you add to the tables.

If you want something like this it's a lot better to just apply the functions to your frames and leave the rest of us alone. Your going to step on a lot of toes if you go with your current way of doing it.

[nightcracker]

Originally Posted by haste Oh joy. Yet another library putting semi-arbitrary functions into on bloated scope while modifying the global environment for everyone. I'm guessing AlarLib was starting to feel lonely... That out of the way; What your doing is really just a bad idea. Your plan to modify the metatable for _all_ objects is just asking for collisions to happen. The chance of it happening increases with every reference you add to the tables. If you want something like this it's a lot better to just apply the functions to your frames and leave the rest of us alone. Your going to step on a lot of toes if you go with your current way of doing it.

Please, just give me ONE example.

[haste]

Originally Posted by nightcracker Please, just give me ONE example.

A collision will happen when someone sets option functions on their frame, which happen to have the same name as yours. If these are used for any type of validation you'll be wrecking havoc on the code following.

Changing the core metatables to include "features" for _everyone_ regardless if they want to have them or not is a horrible design choice. Especially for a "library".

[nightcracker]

Originally Posted by haste A collision will happen when someone sets option functions on their frame, which happen to have the same name as yours. If these are used for any type of validation you'll be wrecking havoc on the code following. Changing the core metatables to include "features" for _everyone_ regardless if they want to have them or not is a horrible design choice. Especially for a "library".

Hmm, collisions won't happen, because that's how metatable.__index works, but I respect your opinion, so my question is, how SHOULD I implement it? Like this?

local lib = LibStub:GetLibrary("LibCoreAPI")
local f = lib:CreateFrame("Frame")

But I hate that I can't use methods like estroy on the Micromenu, for example without having to set them. That's my laziness :P

[haste]

[quote=nightcracker;176460]Hmm, collisions won't happen, because that's how metatable.__index works, but I respect your opinion, so my question is, how SHOULD I implement it? Like this?/QUOTE]
Collisions _will_ happen because of how metatables works.
If I use :Fire() on my frames to execute a temporary queue, and use the function to indicate that there's a need for that queue to be run:
if(object.Fire) then -- will evaluate to true.
if(rawget(object, 'Fire')) -- won't evaluate to true.

And no-one in their sane mind would use rawget to check for that without _knowing_ that the metatable under it could possibly have that variable name.

Originally Posted by nightcracker local lib = LibStub:GetLibrary("LibCoreAPI") local f = lib:CreateFrame("Frame") But I hate that I can't use methods like estroy on the Micromenu, for example without having to set them. That's my laziness :P

Take a look at your code.
local functionName = function(self, ...)
end

when you insert you variables into the frame table (not the metatable) and do: frame:functionName() this translates to frame.functionName(frame), which is equal to lib.functionName(frame) (if the functions are exposed).

This means that it would be possible to use it like a ordinary utility set by doing:
lib.functionName(MicroMenuFrame) (or whatever it's named).

This is of course expecting those functions to be exposed in the lib.

[Rilgamon]

A perfect world is where what you expect is always true.
When writing an addon I have to know what certain values are
at any given time ... even when its unset.

With your aproach all is fine when I use your lib and everyone else, too.
Everyone expects the same.

But we're far from a perfect world. Addons are written, uploaded and
then author stops because he leaves wow.

Do you want to rewrite every addon that is no longer working because
you changed the "default" environment ?

This is not a "**** happens" , addons stop working lots of times.
You're building a lib that will start with "Use it, and its certain **** will happen".

[nightcracker]

I see, I will stop using the metatables. Is it possible though that you(for example) call a function from an other file:

ChangeDefaults()

Like that, and then it has created a LOCAL variable in your current Lua script.
So this would work:

print(something) -- OUTPUT: nil
ChangeDefaults()
print(something) -- OUTPUT: "Yay!"

[haste]

No, functions can't change locals outside their own scope. You can do some nifty tricks with the debug library in Lua which allows this, but we don't have that in WoW.

[nightcracker]

Originally Posted by haste No, functions can't change locals outside their own scope. You can do some nifty tricks with the debug library in Lua which allows this, but we don't have that in WoW.

Hmm, then I'll LibStub it... Is it also bad to MODIFY certain functions(like setsize) so that they can take other parameters(look at my setsize function, it's exactly the same as the original, but will be content with 1 parameter too)? Or like :Hide("forever").

[nightcracker]

Ok, update, I think I will start using metatables again! I check wether the call for the function is by a whilelisted addon, and if not I return nil, giving expected behaviour.

How do I check which addon called the function?

gsub(debugstack(2), ".*\\(.+)\\.+", "%1")

Sometime I think I'm smart, this is one of them(most likely this will get proven otherwise within the hour, but w/e).

[Shadowed]

You're worried about the unmeasurable performance loss of setting a = b. Then you want to do a debugstack and a gsub to search for whitelisted addons, on a function call... ?

[Mikord]

I really wish addon authors would stop mucking about with the global environment. It's never a good idea. I've had to fix several "bugs" that are due to this type of stuff and frankly, it is frustrating.

You asked for an example earlier. Here is some example code that I've seen in a legitimate addon before that your changes would break:

local frame=CreateFrame("Frame")
 
'...
 
if someEventHasHappened then frame.Fire = true end
 
' ...Later in the code
 
' Check if some event should be fired
if frame.Fire then DoSomethingUseful() end

Because you've added a Fire entry that would be detected via the metatable, the check would always pass regardless and you've just hosed this code. It would have to be changed to use rawget. Making others code around you is not very responsible.

Also, what if I were to come behind you, decide to be clever too and create a metatable of my own with some functions *I* think are useful? In the process I blow away your metatables to use my own. Now every addon that makes use of your extensions will break.

I hope you can see why modifying the global environment is just a bad idea. Please don't do it.


Edit:

I see haste beat me to it above. Using LibStub with a specialized CreateFrame call is a much better approach.

Everybody using the global CreateFrame is unaffected as it should be and those who want to use your extensions have an easy way to do so.

[Saiket]

Feels like I'm forum muted.

[nightcracker]

My new system(which is immume to frame.Fire):

local version = 1.0
 
local metatables, registered = {}, {}
local noop = function() end
 
if LibCoreAPI then if LibCoreAPI.version<version then registered=LibCoreAPI.RegisteredAddons else return end end
 
for key, val in pairs(_G) do 
    if type(val)=="table" and val.GetObjectType then
        obj = val:GetObjectType()
        if not metatables[obj] then
            metatables[obj] = getmetatable(val).__index
        end
    end
end
 
local function registeraddon()
    registered[gsub(debugstack(2), ".*\\(.+)\\.+", "%1")] = true
end
 
local function destroy(self)
    self.Show = noop
    self:Hide()
    if self.UnregisterAllEvents then
        self:UnregisterAllEvents()
    end
end
 
local function fireevent(self, event, ...)
    local handler = self:GetScript("OnEvent")
    if handler then
        handler(self, event, ...)
        return true
    end
    return false
end
 
local function fire(self, script, ...)
    local handler = self:GetScript(script)
    if handler then
        handler(self, ...)
        return true
    end
    return false
end
 
local function lock(self)
    self.ClearAllPoints = noop
    self.SetPoint = noop
    self.SetAllPoints = noop
end
 
local function unlock(self)
    self.ClearAllPoints = nil
    self.SetPoint = nil
    self.SetAllPoints = nil
end
 
local function setsize(self, w, h)
    self:SetWidth(w)
    self:SetHeight(h or w)
end
 
local function getclassbycolor(r, g, b)
    r, g, b = floor(r*100+.5)/100, floor(g*100+.5)/100, floor(b*100+.5)/100
    for class, color in pairs(RAID_CLASS_COLORS) do
        if color.r==r and color.g==g and color.b==b then
            return class
        end
    end
    return false
end
 
local function getsize(self)
    return self:GetWidth(), self:GetHeight()
end
 
local function setclassicon(self, class)
    self:SetTexture("Interface\\WorldStateFrame\\Icons-Classes")
    if class then
        local classcoords = CLASS_BUTTONS[class]
        if classcoords then
            self:SetTexCoord(unpack(classcoords))
            return true
        else
            self:SetTexCoord(.5, .75, .5, .75)
            return false
        end
    end
    return false
end
 
local function islocked(self)
    if self.ClearAllPoints==noop and self.SetPoint==noop and self.SetAllPoints==noop then
        return true
    end
    return false
end
 
local function isdestroyed(self)
    if self.Show==noop and not self:IsShown() then
        return true
    end
    return false
end
 
local function toggle(self)
    if self:IsShown() then
        self:Hide()
        return false
    end
    self:Show()
    return true
end
 
local function setshown(self, show)
    if show then
        self:Show()
    else
        self:Hide()
    end
end
 
local methods = {
    Destroy = destroy,
    IsDestroyed = isdestroyed,
    SetSize = setsize,
    GetSize = getsize,
    Lock = lock,
    Unlock = unlock,
    IsLocked = islocked,
    Toggle = toggle,
    SetShown = setshown,
    FireEvent = fireevent,
    Fire = fire,
    SetClassIcon = setclassicon,
}
 
local dependencies = {
    Destroy = "Hide",
    IsDestroyed = "Hide",
    SetSize = "Hide",
    GetSize = "Hide",
    Lock = "Hide",
    Unlock = "Hide",
    IsLocked = "Hide",
    Toggle = "Hide",
    SetShown = "Hide",
    FireEvent = "RegisterEvent",
    Fire = "GetScript",
    SetClassIcon = "SetTexture",
}
 
local mt = {
    __index = function(tab, func)
        return registered[gsub(debugstack(2), ".*\\(.+)\\.+", "%1")] and methods[func] or nil
    end
}
 
for key, val in pairs(metatables) do
    setmetatable(val, mt)
end
 
LibCoreAPI = {
    GetClassByColor = getclassbycolor,
    Metatables = metatables,
    RegisteredAddons = registered,
    version = version,
}
 
setmetatable(LibCoreAPI, {
    __call = registeraddon,
})

If an addon calls LibCoreAPI() then it get's whitelisted and frameestroy() will return the correct function. If it's not whitelisted then frame.Fire will return an not found error.

[nightcracker]

Originally Posted by Shadowed You're worried about the unmeasurable performance loss of setting a = b. Then you want to do a debugstack and a gsub to search for whitelisted addons, on a function call... ?

Nah, I'm not worried, I just was interested in the best practice. Is that really that bad?

[nightcracker]

OK, I screwed the metatables, if I use the above method then it taints the secure functions. LibStub it is!

The first uploaded BETA: http://www.wowinterface.com/download...reAPIBETA.html