lua-users home
lua-l archive

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


> Has anyone else had any experience with binding libraries? Have they been hindrances or helpful? Was performance ever an issue for your domain? I'm curious about the experience for others outside of my userbase.

I never had a performance problem from a wrapper, but I did have difficulties trying to get the wrapper to do everything that I wanted to be able to do. Lua exposes a lot of useful bits and pieces at the C API level, but if the wrapper tries to keep a lot of implementation details secret from you, it may be hard to work around it.

One thing I struggled to do was find a wrapper that I could easily use in concert with lua eris. (Or its predecessor, pluto.)

When using pluto / eris, you need to be able to track down essentially *all* of the C function pointers that you push to lua if you want to be able to serialize the state. Most of the wrappers are trying to conceal the function pointers from you so that you don't have to think about them. Worse, you need to be able to generate those function pointers also when deserializing and all you have is a fresh state -- I don't know a wrapper that provides a way to do that.

I ended up using raw lua C api in my project instead so that I could do this correctly. Gradually I built more and more template code on top of that in order to make things more succinct, and at some point something resembling a minimalistic binding library took form :) So I decided to try to factor it out and make it a standalone thing.

It now lives here: https://github.com/cbeck88/lua-primer

I have written some amount of documentation, but the documentation is not finished and I don't think I would call the library "stable" yet, although it's getting there.

I guess I agree with the idea that thin is best. It feels risky to use a very elaborate library because if you try to do something the maker didn't intend, you can end up with a very complex problem that you wouldn't otherwise have. The thinner it is, the less likely it is to hinder you and the easier it is to reason about resources and performance. It was pretty important to me that the bindings I made try to be cohesive with the lua C api, rather than trying to replace it with something else.

On Sat, Jul 30, 2016 at 6:03 PM, Sean Conner <sean@conman.org> wrote:
It was thus said that the Great Tim Hill once stated:
>
> There is a school of thought here that the best wrapper library is always
> thin; that is, it simply converts the underlying C API 1:1 into Lua, with
> minimal mapping of data types as necessary. I presume the assumption is
> that the less C code there is the less buggy the code will be (which seems
> to assume the Lua code will be less buggy), and that users of the C
> library will be familiar with the API and therefore can re-use their
> knowledge in Lua. I also suspect another reason is to avoid writing
> documentation for a new API.

  There was a thread about this last year:

        http://lua-users.org/lists/lua-l/2015-03/msg00001.html

> I don’t subscribe to this philosophy.

  I don't either, but I suspect we're in the minority.

  -spc