Testing for "class"?

[Rouneq]

Is there a way I can test for an annotated class? I 99% sure the answer is "no" and goes well beyond the capabilities of a Lua interpreter, but I thought I'd ask anyway.

---@class Target
---@field ID integer
---@field Name string

---@param target Target
local function formatTarget(target)
    if (not target) then
        error("no target")
    end

    if (class(target) ~= "Target")
        error("param 'target' is not of type 'Target'")
    end

    return string.format("%s (%s)", target.Name, target.ID)
end

[carsakiller]

The best you can do is probably through metatables:

--- This is your "Class"
local Target = {
    active = false
}

local myTarget = {
    name = "Target1"
}
setmetatable(myTarget, Target)

if getmetatable(myTarget) == Target then
    print("myTarget is child of Target class")
end

See:
https://www.lua.org/pil/16.2.html

[Rouneq]

I've considered that possibility. The problem is I don't own all the data. As I mentioned in another discussion, the game engine returns everything as userdata. I can annotate it, but I can't change it. I suppose I could "scrap" all the data out an put it into my own tables, but that's a lot of overhead.

[carsakiller]

Yeah, if they don't give you the data with metatables already set, you would have to do it yourself

---@class Target
local Target = {}

-- static function for converting data from game into object
function Target.parse(data)
    local obj = {
        name = data.Name
    }
    setmetatable(obj, Target)
    return obj
end

-- method for formatting
function Target:format()
    print(self.name)
end


local rawTarget = game.getTarget(0)
local targetObj = Target.parse(rawTarget)
targetObj:format()

[carsakiller]

Alternatively you wrap the game.getTarget() function entirely within the Target class, something like Target.new(), which is probably a better idea. I mainly develop Lua when targeting a game environment too and Lua is pretty dang fast so overhead shouldn't be too much of a problem unless you really start messing around with metatables. I think any reasonable amount of slowdown incurred by something like this is a worthy trade-off when it comes to readability and ease-of-use code-wise.

I usually end up have to do some wrapping similar to the above if I want to use OOP in games (SOOP as I call it in Lua - Scuffed Object Oriented Programming 😉)

[carsakiller]

I've never had a game return userdata before so I'm not too sure how it works, but it may already have a metatable linking it to an Object from C?

They are most useful for holding data that is useful from C, but which must be managed from Lua. They support individual metatables, which are the key feature that allows binding C or C++ objects to Lua. You simply populate its metatable with methods written in C that access, modify, and/or use the content of the userdata, and the result is an object that is accessible from Lua.

~ https://stackoverflow.com/a/4332717

[Rouneq]

From another SO: https://stackoverflow.com/questions/55338482/how-to-modify-a-metatable-which-was-created-by-c-api

Userdata is meant to be created by C, manipulated by C code, and for only the purposes that C code intends. Lua can talk to it, but only in the ways that C allows it to. As such, while userdata can have a metatable (and those metamethods are the only way Lua can "directly" interact with the userdata), only C functions (and the debug library, but that's cheating) can directly manipulate that metatable. Lua is an embedded language, and C has primacy; if some C library wants to shut you out, it can.

[Rouneq]

I think I'll forgo any crazy shenanigans. While the code isn't specifically meant to be shared, the spirit of the support community is very much set up to encourage others to take the contributions and modify them. And I'm making something intended for others to use. Publishing the script(s) + annotations/wrappers is a major difference than how it's currently done. I'm not opposed to going against the trend, but in this case, the effort would be wasted.

[Rouneq]

As suspected, the answer is "no". Or, at least "no" withing the confines of my working environment. Thanks for the feedback.