On 15 December 2010 15:56, Tim Mensch
<tim-lua-l@bitgems.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12/15/2010 4:19 AM, liam mail wrote:
> My observation for Open Source projects is that a large number do not
> get a lot of feed back until something does not work, so I would be
> really interested in what you found awkward to use with OOLua so that I
> may address any issues.
Well, the fact that you need to list every function twice, figuring out
which list to put it in the second time, is awkward. The fact that you
need to list parameters for functions is awkward.
SWIG and tolua++ allow you to copy-and-paste from headers, which means
even though they require the same information, it's far less awkward to
supply it. And LuaBind does reflection to detect the parameters. I want
to be able to list the functions I'm using, AT MOST, once. In OOLua you
not only have to list them twice, but once they go in a header, and once
in a compiled file; as far as I'm concerned the header/implementation
separation of C/C++ is a design flaw, and that basically ends up
doubling the impact of it, since each new function you write now needs
to be in four places instead of one.
And the complete lack of up-to-date documentation is a real bummer.
"Read the tests" does not substitute for clear (indexed!) documentation
IMO. Sorry.
> PS the OOLua link in the blog post is broken,
Thanks; fixed.
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNCOUzAAoJENSbqLBCyKKs1qQH/Arol9SMEhH22KPvZpUV/JuH
ubQvzM7UK++GjZNIxVAPf8jbb6CU0Erxv252qeKCykfTVpba3PnXQ2i711/huUvA
bQ0XZF6Bqj8ZsNL7mHHH4MKDQh6WdvtzSeTAoxLS7IT/JASQ1uNugRc9tDiCnaq6
IEWJwstG6OwmH8C+Fg9kjUG+fvtJ5hopglGl8aTsNW+nBm0Mi2RV8qG147omDPHE
Q5rUzzZyyFHqJw5NliQdIZzCpc/bRI/sxeAJ9H9zM+6Th+n51eriTqRT4MNwHT3i
sjWYTsXt8VBAF5pDtCQGOvbiIo128OfON2ShcLBrODEWNgm55yB3vuHDnwP4xpQ=
=6vW2
-----END PGP SIGNATURE-----
The two awkward aspects which you identify are a mostly the result of the design for the library to fit it's requirements. The facts are that for Lua to call C/C++ functions by name then generally a string and a function address are required. Now comparing how apple and orange implementations do this when they use different binding strategies is interesting although not really relevant; yet I agree that supplying the function name information in two places is not ideal but this is just something which OOLua has to live with. Automatic bindings that have a preprocess that add this data for you whilst runtime constructed containers of attributes and functions take the information which you provide. It is whoever possible to enter the data a second time in the header but none the less it is still required to be initialised somewhere and as you correctly mentioned C++ has a one definition rule. OOLua is not an automatic binding and also does not use a runtime assembled proxy class.
With respect to needing to supply parameters, so if I am correct then what you find awkward is not the way parameters use traits yet the fact that parameters are actually needed?
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. 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.
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. There is some documentation for OOLua yet it is not a complete reference and is in the form of a cheat sheet or getting started document.
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.
Thanks Gaspard for mentioning dub, I will have to see if this is the holy grail of C++ and Lua automatic bindings everyone is looking for.
Liam
