[help] Exporting OOP classes with functions

[rain_gloom]

Let's say I have some OOP code that I want to export. The OOP follows the basic metatable approach, but for demonstration purposes consider the following code.

How do I export this?

someNamespace={} 
function someNamespace.myFunction() outputDebugString"Yay, I ran!" end 

[Addlibs]

I don't really know if it's possible to export functions within lua tables - the only possibility I know would be to make a specific function that would return that 'namespace' which contains your functions...

function getNamespace() return someNamespace; end 

(of course it that 'getNamespace' function would have to be defined as an export in the meta.xml) and then called by

exports['your-resource']:getNamespace().myFunction() 

I'm not entirely sure but I think that functions within that namespace don't need to be added to exports in meta.xml

[rain_gloom]

Tested it right now. I printed all keys and the only one it had was __index, which is also the only one with a non-function value.

*sigh* I guess I'll have to use the functional syntax.

Or I could just load the script into every resource that needs it. But that would be a waste of good memory and inelegant. So not in the Lua way

[JR10]

Another approach would be something like this:

local classCode = [[ 
  
Class = {} 
Class.__index = Class 
  
function Class.create() 
    return setmetatable({}, Class) 
end]] 
  
function getClassCode() 
    return classCode 
end 

And then at the start of your other script:

loadstring(exports.myresource:getClassCode())() 

[rain_gloom]

Yup, I've tried that, but that's very redundant.

I'm going to test exporting without the OOP format. As in:

namespace={} 
--OOP definition 
function namespace.foo() return "bar" end 
--May be exportable through this name? 
namespace_foo=namespace.foo 

and then:

<export function="namespace_foo" type="shared"/> 

Will edit with the results.

Since I started working on implementing a pre-processor, I could add an automatic converter for exported OOP functions this way.

Even if it works, it loses the whole point of OOP. Well, the syntax at least.

[ixjf]

Don't bother trying. It's not possible. You can't copy functions to other Lua VMs.

[JR10]

Yup, I've tried that, but that's very redundant.

I'm going to test exporting without the OOP format. As in:

Even if it works, it loses the whole point of OOP. Well, the syntax at least.

Even if that works, what if you want a namespace.create() function that returns a new object. It won't work, I tried several things before, none worked.

[rain_gloom]

Even if that works, what if you want a namespace.create() function that returns a new object. It won't work, I tried several things before, none worked.

I guess metatables won't work, but I only use them for the OOP syntax in this particular case.

Just think about it, all that the 'myObject:method' notation does is it inserts an implicit 'self' as the first argument.

Yes, I won't have OOP methods, but I'll still be able to use the old MTA syntax, as in:

classnameDoSomething(classObject) 

Here is the relation in detail:

class={} 
class.__index=class 
function class.new() 
return setmetatable({num=0},class) 
end 
class_new=class.new 
  
function class:setnum(x) 
self.num=x 
end 
class_setnum=class.setnum 
--the above function's formal description will actually become this: class.setnum(self,x) 
  

An OOP call in Lua looks like 'obj:method(...)' which is shorthand for 'obj.method(obj,...)', but of course we know that the 'obj.' can go through __index, which allows the object to inherit its data from another table.

If we sacrifice that kind of call syntax and all metamethods, the code can be exported without redundancy in the memory.

I really hope the MTA team is going to fix this though, but since OOP in MTA is still relatively young, I think it is forgivable that they have not yet done it.

[JR10]

You could suggest something on the bug tracker.

[rain_gloom]

Thanks, already have done so

We'll see what the dev team can/want to do.