Module name + README mismatch with build.zig.zon

[robbielyman]

follow up from #136: testing locally, with zig fetch, the package now is named lua_wrapper in build.zig.zon dependencies by default.

how do we want to proceed with the module that we export? ziglua is, within a zig project, slightly redundant, as observed in the rationale that led us to change the package name. on the other hand, just using lua feels slightly inaccurate: for one thing, the Zig module is more than just linking against the C library, and for another, the word Lua is already pretty heavily in use in the module itself.

[nurpax]

I don't know how I would name it inside the lua_wrapper project, but I think in my projects I'd use it like this:

const lua = @import("lua_wrapper");
const Lua = lua.Lua;

...
and for top-level functions: lua.wrap, lua.FnReg, etc.

Furthermore, if I can't do lua: *Lua in my functions anymore (because of forbidden name shadowing, which I hate in Zig), then I'd probably switch those to lua_state which might actually improve readability slightly because previously there were too many "luas" in my code. :)

[robbielyman]

heh, i usually have those function parameters as l, since i am living on the edge or something. what you have written seems fine. the @import("lua_wrapper") call makes me think you're in favor of changing the Zig module we export from being named "ziglua" to "lua_wrapper", is that accurate?

[nurpax]

I don't use l because it looks too much like 1 in some fonts. Some old habit, probably some compiler lint rule compiled about it and the habit stuck with me. :)

Yeah, I think the exported module should be lua_wrapper. Wouldn't it be odd to use ziglua here?

[natecraddock]

I think it would be weird to clone ziglua, add a lua_wrapper dependency and then import a ziglua module - maybe too much back and forth with naming

I wonder if it's reasonable to move all of the public declarations in the module to be inside of the Lua opaque? Then the import could be const Lua = @import("lua_wrapper").Lua

[nurpax]

If that was the case, why not just const Lua = @import("lua_wrapper")?

I actually think the current Lua type makes sense. I see it as the "lua instance" or state which is operated on with the member functions. But there are other functions like some business related to Luau compilation that is at the top-level and I think it's sensible that these are not inside the "Lua state type".

It could be argued that may the name Lua is not great for this type. For example, what if it was called VM or Interpreter -- it's intent would be more clear.

But really, I at least admit that I'm in the bikeshedding mode here.. I absolute don't mind using it like const Lua = @import("lua_wrapper").Lua.

[robbielyman]

ah, yeah thinking about Lua as the VM instance is useful. well, ok, sounds like we agree though that the module should be lua_wrapper.