Non preprocessed E2 api

[Vurv78]

The extension preprocessor has caused a lot of pain throughout the years with breaking editors.

So a pure lua api to create E2 extensions would be quite nice.

It's possible that this simple Emmylua/LuaLS annotated code could work as an extension, registering a function test(sn)

--- Does the thing
---@cost 5
---@param a string
---@param b number
---@return number
function test(a, b)
    return 5
end

How would it work? First, to know what functions are being defined in the first place, extensions would be run in an fenv that detects exporting functions (via __newindex). Second, to actually get information about the function, debug.getinfo could be used to read the file, and scan the emmylua annotations provided to the function.

So this works perfectly fine, but the question is whether this is perfectly sane:

Already this causes a linting error from exporting a global with a lowercase name, and this doesn't immediately look like you're exporting an E2 function, which may be very problematic, so, two alternatives could be done, either:

---@param a number
local function test(a)
end

pseudoRegisterFunction(test)

or

local e = pseudoCreateExtension("propcore")

---@param a number
---@param b any[] # `array` type
e:registerFunction("test", function(a, b)

end)

As for methods, likely a registerMethod function would be needed for the last two examples, the first one could theoretically also look like this with more metamethod magic, but it feels unholy at this point:

-- entity variable is undefined, fetch it via __index, detects __newindex on that with a function, boom, create method.
function entity:foo()

end

Another idea I had a while back was to have types shared as objects, and you'd reference them this way, so the same idea except instead of depending on the fenv, use the proper type, which is not as hacky.

local entity = pseudoFetchType("entity")

function entity:foo()

end

Both of these don't type the self variable in your editor, however.

Creating this discussion far in advance so we can get opinions on how this api should look. This would be the final api for E2, after all so it should be quite future proof.

[Denneisk]

Global metamethod magic would just look so nice, to have E2 functions defined so seamlessly.

[Denneisk]

Something that needs to be considered is handling E2 libraries that expose things globally/to Wirelib. Maybe that's more of a fault of the libraries though.

[Denneisk]

Thinking about it again, maybe we could just copy SF's way of doing it. E2 will require (re)writing a documentation generator for it, anyway. Simplifying function definitions to not be a mess to maintain for us will be better. Could also coincide nicely with #3071; let legacy (preprocessed) function definitions continue to use the old path and new function definitions to use the new one.

[Denneisk]

As for methods, I think it should be linked to a type that can be a prototype if it's not properly defined, in a similar way to how you describe for extensions.

local entity = getType("entity")

entity:registerMethod("name", ...)

local nonexistent_type = getType("whatever") -- Get a type that doesn't exist

nonexistent_type:registerMethod("name", ...) -- Could error/warn if type is never defined at end of setup

This avoids having to care about order of execution and having to load the extension twice.

[Denneisk]

Rereading what you wrote, I guess I just repeated what you already said. Regardless, we should just aim for simple solutions. Extension developers won't need their hands held.