Conventions for a module that's part C, part Lua

Question

In my application most modules aren't pure Lua, or pure C, but hybrid.

I wonder what's the recommended "layout" for such modules.

So far I've found two approaches:

1. The posix module uses the name "posix_c" for the C module. Users aren't supposed to use this module. The Lua module, simply named "posix", imports (and augments) this module.

2. The Awesome window manager exports the C part of the module to the global namespace. Since this name isn't in package.loaded, the Lua module can have the same name.

What is the method you recommend? Are there other approaches?

Answer 1

If users aren't supposed to use something then it should be hidden: either in registry or completely hidden in Lua module's upvalue. That's for calls from Lua to C. For calls from C to Lua the only option is registry, but it can be used in non-conflicting ways if needed, as described below.

Since it's your app you can simply rely on registry itself. In my apps I register internal C functions in it and also assign Lua callbacks there from Lua side. E.g. one of things my Lua core scripts start with is local internal = debug.getregistry(). When all core scripts are loaded I can do sandboxing, disabling access of regular scripts to debug library etc.

In case you want to make a stand-alone module I'd suggest doing a C module that would call Lua script when loaded, passing the "hidden" table to it. For calls from C to Lua, C code can use address of any variable in the module as light userdata key to store the "hidden" table in registry.