Re: Lua binding compare-and-contrast

[Tim Mensch <tim-lua-l@...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/15/2010 4:52 PM, liam mail wrote:
> The two awkward aspects which you identify are a mostly the result of
> the design for the library to fit it's requirements. 

Sure. I understand it works that way because it's the way you want it to
work. But you asked. :)

> The facts are that for Lua to call C/C++ functions by name then generally a string and a
> function address are required. 

See what I ended up with in Playground [1] (sitting on top of the
LuaPlus callback dispatcher [2]): It registers a function with arbitrary
parameters that are extracted using template code with one call. Each
parameter is validated, and it's easy to add custom parameter types.

For instance:

SomeClass * foo= /*something*/;
ScriptRegisterMemberDirect(L, "MyFunction", foo, SomeClass::MyFunction);

This works well for exposing global functions that are bound to a
particular instance of a class in C++ (full example at [3]). Playground
(and LuaPlusCD) doesn't attempt to bind objects, though, just member
functions to specific class instances, which is why I was looking for a
new approach. But there might be some way of marrying the two approaches.

Large parts of Playground, including the code that handles this, are
open source, and free to download from [4]. So feel free to take a look
if you care.

> When creating the library I tried to provide a clean and consistent way
> or proxying a function, you may have ran into one of the problems which
> I needed to avoid in that C++ allows multiple functions which the same
> unmangled name that have different signatures. When this happens in
> LuaBind you give it a helping hand by casting the function to the
> correct signature when registering the class. 

I think that technique would work with the macro above, though honestly
I just avoided trying to bind overloaded functions to Lua.

> OOLua can not do this and
> as a result the design forces the user to use a consistent method whilst
> also allowing you to specify special traits for the parameters.

Traits are good, sure. If listing parameters were optional, that would rock.

> I have communicated with you before and therefore we both know how each
> other feels about documentation. In my eyes it is a liability that has
> the potential to be always wrong, whilst unit tests always show the
> correct behaviour and usage otherwise there is a bug; on the other hand
> you like to have reams of documentation on everything. 

Playground has over 500 pages of docs [5], 95% written by me (and
Doxygen), so I guess that's a fair assessment. I'm sure you're right,
and that there are bugs in the docs. But in any complex library, a few
use cases that the developer thinks are important to put in the unit
tests are not going to be sufficient to explain how something's intended
to be used.

I think the best approach is to have both unit tests that are known to
run and documentation describing how the APIs are intended to be used. I
know I wouldn't have even considered OOLua if the CheatSheet didn't
exist. Different people have different learning styles, and to only
cater to one means you're leaving out half or more of your potential
audience.

> I thank you for highlighting the issues which you had problems with. If
> you do consider these awkward aspects it maybe the result of a bad
> design in the library; yet it does fill all my requirements and I
> realise that not everyone will feel the same or have the same requirements. 

It's not any worse than the design of C, and you'll find thousands of
developers who will tell you that C is the one of most elegant designs
for a language. I think Lua beats it by miles, but maybe that's just
me. :) And if my criticisms came off as harsh, I apologize. Sometimes in
haste I'm not as diplomatic as I could be; I know you've worked hard on
the library, and that you work hard on helping people use it.

And I did appreciate your quick help when I was first trying out OOLua;
we got it almost to the point where it had all of the features I needed,
and I don't want to sell you short.

Thanks again,

Tim

[1]
https://developer.playfirst.com/docs5?file=d1/dae/group__luadocs.html#g96cc82ef6e2531397ba5236da466fb44
[2]http://wwhiz.com/LuaPlus/LuaPlusCallDispatcher.html
[3]https://developer.playfirst.com/docs5?file=luascripts.html#luagamescript
[4]https://developer.playfirst.com
[5]http://www.lulu.com/product/paperback/navigating-the-playground-sdk%E2%84%A2/4634509
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNCpRmAAoJENSbqLBCyKKs+tkH/3txPxQfjNRT1zf9whHDuRQu
k+uUF0Zn96Duse0HYJdkN86K+pUksm4LwsgnJIUhh0Of/YK9Hyy+kRtZRuDFFqUd
MrTFIOxGR3IBMPlVurHENHQPiRMmNnGiLi2laBvLnitfDB4f7mx0VwSFnr1viPbE
vEPIS0DLrsG7TdC/exhg6zs4XU/NCY8V4Sux8rSe2iUSlo1yAY0tFGW1ZHTDrovx
W7JmCGxZSMjOiluA8sHo6urO4AZKuCFTuB410beIUs8cyFhWpntMM6GX63Cxcpal
IpNhPaGLKSU7qGtz+2JJkbe17l0ZAXRa6HDXcWd3pc+dg0nv7WL3UZiWWFiAsjg=
=++Jp
-----END PGP SIGNATURE-----