Re: Modern Lua binding library

[Sean Conner <sean@...>]

It was thus said that the Great ThePhD once stated:
> Dear Everyone,
> 
> I *STRONGLY *disagree with always defaulting to the C API. While it's good
> for quick things and hobby projects, the C API lacks the ability to scale.
> Writing large applications where you're writing -- and re-writing (or
> copy-pasting) -- the same code over and over again with slight tweaks just
> to call a function or something is not okay.

  I've found that I rarely ever call more than one Lua function from C code,
and that's usually to start the Lua code running.  The C code exists to do
those things that I cannot do from Lua (create a socket, convert an Xlib
event to a Lua table, etc).  The main application is written in Lua.  If I
wanted to write an application in C, I know where to find it.

> This is *BAD*. It's error-prone. It's sluggish. It's just not what you want
> out of an API. If I can do
> 
> f("hi", 24, 56)
> 
> In Lua, I deserve something that allows me to do
> 
> f("hi", 24, 56)
> 
> In C++. We can tote how easy it is to use the Lua C API -- and it's fine
> for implementing things quickly or being the underpinnings of a library --
> but it is NOT ideal. It is NOT the best we can do. We can do better. And we
> do deserve to have libraries that make it better. Libraries that allow us
> to do [ Selfish plug ]:
> 
> sol::function f = table["f"];
> f("hi", 24", 56);

  Okay, so does your binding library handle this?

	sol::function f = table["g"];
	g(lua_variable_x,cpp_variable_y);

(and just in case it isn't clear, "lua_veriable_x" is a variable defined in
the given Lua state, and cpp_variable_y is a C++ variable).

  -spc