Object-based MMF Interface

[Retriever2]

I've been experimenting with an object-based model for XLua's MMF interface, which would exist as a separate loadable library (and maybe some time in the future the increasingly large interface would be separated from the XLua core). How much interest would there be in this kind of model?

Instead of exporting an ID and passing it to each API call to interact with an object, the object would be exported as an object table, assigned to a variable of your choice. You'd be able to directly read or write most attributes, other methods would exist as member functions, e.g.

-- Some object is exported to the variable 'obj'
local xCoord = obj.x
obj.angle = 45
obj.values[3] = 100
obj.moveToFront()

Each object would only expose fields and methods it safely supports. You could add new fields to the tables to hold associated data without affecting its MMF state. There's also the possibility of directly representing different kinds of objects, like object classes, collision masks, surfaces, etc. Some of the API would continue to exist in its current form, the parts that deal with global state and don't require object IDs passed around.

The tradeoff is a small speed hit for the meta-indexing, but probably less than if you were to implement similar management on top of the existing API.

[Corentin]

I think it's a great idea. I'm not very used to Lua yet, but I think this syntax would be far easier to read/write/understand/debug, and most of the time, performance is not a big problem anyway.

Users that really need critical perfs are aware this could be a bit slower, and will avoid using this system.

[Looki]

It does look very promising, I myself always would have preferred having the MMF interface object-based, but never asked whether you would realize this one day; I thought there wasn't much general interest in this. Anyway, as I said, I'd love this, and I wouldn't mind a minor speed hit.

[Atom]

This sounds great

[Forum User]

That sounds beautiful! These are all things I would have loved to have seen in Lua+, so it's great to see them being implemented in XLua. Kudos!

[xyzzy]

sounds good to me

[Retriever2]

sounds good to me

Well you already got the sneak preview anyway.

I'm glad to see the positive response.

[MechatheSlag]

Very neat, while already somewhat possible to do with the current api, the above would definitely make things a lot easier.

[Retriever2]

At the same time I am expanding the API in ways not currently possible

[Retriever2]

I want to take a moment and share (in code) some of the way things are changing

-- On the frame, we've created a bunch of instances of a "Goomba" active object.  We've also got some "Koopa Shell"s

-- An object class represents an object collectively
-- An object represents a single instance
goombaClass = mmf.NewObjectClass("Goomba")
koopaShellClass = mmf.NewObjectClass("Koopa Shell")

-- We can get objects from a class
goombaList = goombaClass.objectList()

-- And operate on them all
for i,goomba in ipairs(goombaList) do
  if (goomba.overClass(koopaShellClass)) then
    -- When we destroy an object, the lua table backing it will
    -- disable itself, so even if we try to use it we're safe
    goomba.destroy()
  end
end

-- We can store our own data or methods with objects or object classes.
goombaClass.step = function(obj)
  obj.x = obj.x - 1

  -- Speaking of names, now you can access alt values and strings
  -- by their names if you defined them in the editor
  obj.y = obj.y + obj.values['gravity']
end

for i,goomba in ipairs(goombaList) do
  -- Note, I still need to do some exploring but I may be able to
  -- get proper inheritance working with these special objects, thus
  -- avoiding needing call the class method via the class object
  goombaClass.step(goomba)
end

-- What am I doing here?
goombaClass = nil
collectgarbage()

-- Oh no, I lost my class object with my custom defined method!
-- But actually...
goombaClass = mmf.newClassObject("Goomba")
goombaClass.step(goombaClass.randomObject())

-- ... the function is still there.
goombaClass2 = mmf.newClassObject("Goomba")

-- In fact goombaClass and goombaClass2 are the same table.  The
-- library will keep a persistent reference of every object or 
-- object class created, and always return the same table.

So that's a little preview of the new things I've accomplished with the library.

I'd like to hear anyone's suggestions on how you think the API should be designed, what should be included, issues like 1- vs 0-based indexing, etc. I never went out looking for input the first time I designed it, but now's your chance.