Hi, I am currently integrating Lua into one of my projects. This mainly uses Luabind. For those who have experience in implementing scripting: Do you litter your code with open lua calls (so, for example, use luabind in the same way you might use the STL), or use a facade class to provide a "ScriptManager" interface for all Lua calls? There seem to be conflicting issues. For example, calling a function using luabind uses: template <class Ret> Ret call_function(lua_State*, const char*, ...) As far as I am aware there is no easy way to pass ... through to a function call, making implementation of a wrapper function awkward (as it so happens, I had already written my own wrapper for function calls using boost::tuple, which I prefer). Similarly, writing a wrapper for the class definition calls is complex - complexity that is already handleded for you in the luabind libraray. So the trade off appears to be between the complexity / time burden of writing wrappers for existing library functionality; versus the benefits of localization of all the library code, something I have always assumed is seen as a good thing. Any thoughts? Jim.

Quote:Original post by JimPrice
For those who have experience in implementing scripting: Do you litter your code with open lua calls (so, for example, use luabind in the same way you might use the STL), or use a facade class to provide a "ScriptManager" interface for all Lua calls?

LuaBind is the facade. Don't make a hammer factory factory.

Quote:As far as I am aware there is no easy way to pass ... through to a functioncall

I'm not sure what you mean by this. Are you having trouble using things like boost::bind with vararg functions?

Thanks Sneftel.

Quote:
LuaBind is the facade. Don't make a hammer factory factory.

Yeah, this is what I was starting to feel like. The problem was I started off writing a facade using lua API calls, and then started to integrate luabind after I had already written a fair bit of functionality (plus it was the first time I had really used type-traits on any great scale, so I was all excited). Then, as you say, it started to look like a hammer factory factory.

Quote:
I'm not sure what you mean by this. Are you having trouble using things like boost::bind with vararg functions?

I was under the impression that this sort of thing wasn't valid code in C++:



Now you are of course either a) You are going to prove me wrong; or b) I am going to look up boost::bind and find all my childhood dreams about ellipses answered.

Thanks,
Jim.

Well, let's see. You can't exactly proxy varargs functions natively in C or C++, no. (There are ways around this, if the library author gave you them; see, for example, vsprintf.) But when would you want to do this? I can't think of where you'd want to proxy call_function in general, only where you'd want to call it with a specific argument list.

The issue with ... Sneftel was writing the facade - call_function takes a ... parameter, so if I was writing a facade for luabind I would have needed some way to pass a variable length of parameters to this function - hence in my example above foo could be renamed call_function and bar the facade callthrough.

However, this is all now academic, because I am no longer wrapping the luabind library.

Jim.