Jump to content

[help] Exporting OOP classes with functions


rain_gloom

Recommended Posts

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

Link to comment

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 :/

Link to comment

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())() 

Link to comment

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.

Link to comment
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.

Link to comment
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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...