Closed rbartlensky closed 5 years ago
Addressed all comments. I've added some extra explanations for the handler. Ready for another review.
Ok, so now I have a LuaClosure
trait object, which has the same methods as before, but has an extra call
method. This call
method is different depending on the underlying object. A UserFunction
will call vm.eval
, and a BuiltinFunction
will call (self.handler)(vm)
. One problem with this approach is that I can't have a Gc<LuaClosure>
, only a Gc<Box<LuaClosure>>
which means extra indirection. Also, when handling calls I have to do an explicit clone of the current closure, however, Gc::clone
simply does a Cell::new
, which AFAIK doesn't involve any heap allocation, so this operation is quite cheap. Why do I need to clone? This is because call
takes a mut& Vm
, thus vm.closure.call(vm)
will trigger a borrow checker error.
Ready for another review!
Please squash.
Done!
This PR adds an implementation of the print function, and extends the VM to allow closures to have a handler. A handler is a function defined in the vm, which is associated to a
LuaClosure
. If a closure is called and has a handler, the vm will call a rust function (which is the handler) instead of callingvm.eval
.The integration tests will be improved in my next PR where I will add the
assert
function.