lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I've certainly thought about it, but so far I've chosen to avoid going
that route for a few reasons:

One of HenchLua's primary design goals is to keep the amount of
garbage generated during operation at an absolute minimum. With very
few exceptions, HenchLua is set up to avoid allocating new objects in
cases where standard Lua wouldn't touch the allocator. Reflection,
since it passes arguments and return values as objects and arrays of
objects, intrinsically creates garbage during normal operation. So
that sort of defeats the whole purpose of not just using KopiLua in
the first place. The only way I know of to use reflection without
creating garbage is to autogenerate and precompile the binding methods
at application startup, however neither Reflection.Emit nor
Expression.Compile are available on a number of the platforms we're

Second - HenchLua doesn't lock all of its data up behind the stack
interface. You can use tables directly much like you'd use a .NET
Dictionary (both initializer and foreach syntax supported). As far as
passing arguments and return values goes, you still need the stack for
that, but the syntax is a little less painful `(int)l[2]` vs
`lua_tointeger(l,2)`, and also check out Thread.SetStack, which makes
returning small numbers of values at once simpler than the usual group
of stack ops (you can see it in action in BNext -
So it's not ideal, but it's better than standard Lua, and that leaves
me less motivated to put a lot of time into complex automagic binding

That said, nothing stops anyone from writing or porting a binding
library to HenchLua's interface. I may even do that myself one day.
But right now it's somewhat counter to the project goals and a fairly
low priority for me.

On Fri, Sep 6, 2013 at 3:21 AM, steve donovan <> wrote:
> On Fri, Sep 6, 2013 at 11:44 AM, Phill Djonov <> wrote:
>> Comments, bug reports, and patches are very welcome.
> Have you thought of adding the LuaInterface reflection stuff, as has
> been done with KopiLuaInterface?
> It really does make accessing .NET objects much easier.
> When I was messing around with KopiLua, the weaknesses I found came
> from half-assed implementations of C runtime functions that the Lua
> core depends on. But then KopiLua is a very _straight_ port of the VM
> ;)

Phill Djonov
Programmer, Tools and Graphics