Re: How close to C do you make your binding?

[William Ahern <william@...>]

On Thu, Jun 19, 2014 at 08:07:09AM +0200, steve donovan wrote:
> On Wed, Jun 18, 2014 at 9:09 PM, Aaron Faanes <dafrito@gmail.com> wrote:
> > power and flexibility in writing a binding directly. A binding is a
> > translation, so the original source should be respected as much as possible.
> > This strictness gives people the freedom to use the original documentation
> > (as was mentioned) and forget that they're using a binding much at all.
> 
> This is true, and appears to save the binder writing documentation for
> the idiomatic Lua API.  It makes sense to the binder, because they're
> fluent in C and can read any tutorials for the C API.  But it poses a
> problem to a more casual user, who may not know C.  So it's worth
> going the extra mile; and the thread (of course Coda!) is about doing
> the extra idiomatic layer in _addition_.  Depends totally on the
> intended audience of course.

And the C API! A good C API is modular and consistent, and ideally eschews
things like callbacks and complexing classing, and has simple and clear
ownership semantics which allow code composition (e.g. supports simple
reference counting with acquire/release methods), and simple and consistent
error handling. That makes writing bindings much more natural, so that the
Lua API and C API naturally mirror each other yet still allows freedom for
obvious tweaks in the direction of idiomatic Lua when it comes to handling
errors, etc.

I always write my C code with an eye to binding in Lua, Perl, etc. Even if
it never happens, it's a habit which improves the structure of my code.

If the C API sucks, then that's a huge burden on the binding author. And of
course automatic bindings are out of the question if you care about quality.
If the C API is good, then binding is simple, you can easily tweak things to
support idiomatic Lua, and you probably don't even want to bother with an
automatic generator.

Often times if a C library looks difficult to write bindings for, and will
introduce limitations or caveats as far as how it can be used in Lua, then
that's a strong signal that it's a library I don't want to be using in my
project.