[q2x] OT: Lua questions

[Nick Trout]

> Right, that's what I was going to do, but the Wiki uses the metamethod
technique, so I was left rather confused.  I'm currently using the
metamethod technique with some success.

I wouldnt use the copy/clone method because it seems inefficient, each
object having a complete copy of its methods. However this technique of
programming is quite popular I think. I think languages that do this are
called prototyped languages, e.g. Apple Newtonscript was quite popular. Not
sure of the implementation details there though.

> > The advantage of the metamethod solution is you only have one
> instance of the methods. The instance contains your member
> variables, but then you have a table which contains your methods
> (kind of like they're static). I suppose it's a bit like a vtable
> in C++. You can also then overload various operators, e.g. +, - etc.

> If I use the metamethod solution, does that mean I can't overload?
c = classdef:create()
c.some_function = derived:somefunction
-- or whatever the syntax would be...

No, you can overload, it just depends how your metamethods are set up. The
usual way is inheritance by delegation. You look at the local method table,
if the member is not there you delegate a parent to look at, thus if you
have the same funtion locally you have overloaded it.

Another way of doing it would be, as described in the last email, by
aggregating all of your methods when the class is instanced. You could check
to see if the inheritance hierarchy you have has been used before e.g.
object : shape : triangle. You could then collect the methods from object,
then shape, then triangle and overload as you go down. These methods could
all live in a single unique method table for that particular hierarchy. If
you had object : shape : box, that could live in another. If you made
another instance of triangle it could used the caches method table to save
duplication. This solution would be faster than delegation since you have no
runtime overhead, just a single table lookup, and you have slight overhead
of one method table per hierarchy.

Lua is wonderfully flexible though, you can pretty much set it up however
appropriate.

> > If you run a file in a state, over a previous run then you'll
> probably destroy all the objects that were there, replace them and
> cause them to be garbage collected.

> That's what I feared. =|
Let's take a simple example.  Say I have a function like:
function object:do_something()
end

> It's in its own file, object_do_something.lua.  No other objects are
defined in there, so I don't have to trash any global variables.  Now,
I edit and change that function.  The big question is (assuming
nothing is in the middle of executing): will all previously created
objects automagically reference the new object:do_something, or will
they just vomit and die?

This is where things could get messy. If you have references to objects, the
references will still reference the old objects. Just think of the
references as pointers to the objects. It's the same thing in C, if you
created a load of new objects, you wouldn't expect your pointers to
magically be directed to the new objects. Whatever you want to happen when
new objects are created is really application specific.

However, if you referenced your functions by string name, rather than
variable name it should work.

The following:

t={}

t.foo = function(x)
        print(x)
    end

foo_ref = t.foo   -- reference formed

foo_ref('hello')

t.foo = function (x)
        print('no!')
    end

foo_ref('there')  -- called using reference
t.foo('there')   -- no ref
t['foo']('there')  -- same as above

-- prints:

hello
there
no!
no!

So, don't make references to objects if you are going to replace the
objects. This is something that you need to be aware of when you are
scripting using garbage collected languages, any language, e.g. Java,
Python, Lua etc. If you use the table to access the object you should be
fine, i.e. t.foo or instance:foo()

Nick