[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [LuaJIT FFI] Recommended policy for exposing FFI functions
- From: "Dimiter \"malkia\" Stanev" <malkia@...>
- Date: Mon, 01 Aug 2011 01:25:46 -0700
First I'm not your general lua user, or long time lua coder, nor a long
or so active member of this very awesome lua community.
As for exposing it, I'm going with no hiding whatsoever, in fact I try
to reuse native types where I go, and actually use them as "first" class
citizens (more like H1B workers, but eventually getting green cards at
But not always. I have found that string handling is better than better
in lua for what I need, so instead of keeping "char[?]" or "char*[?]"
around, I might convert result back to string, or return table of it.
So I'm being dualistic - I use certain things directly in FFI -
vectors, matrices, and others in Lua - table with strings, or
properties, etc. I don't even have problem keeping what starts from 0 or
from 1 - as I clearly keep the distinction between two of them (I know
luajit is efficient with normal lua tables starting from 0, but certain
lua idioms fail to be understood at this point, which would not apply
for the luajit array cases, I'm talking about t[ #t + 1 ] = value, and
Now again, I don't see myself as regular user (yet), but LuaJIT so far,
and my goals do not go in the same direction of established developments
such as luarocks, or others. I even go and recompile the libraries in
ways that allow me better reuse (for example had to turn off #pragma
pack(4) for Windows (MSVC) SDL 64-bit build - as it simply made no sense
- keeping 4 bytes less here and there for miniscule structure, and then
only for certain compilers).
I'm still thinking of how to structure my ffi bindings, and extensions
for them for more lua native usage. Should my extension be given as
parameter the ffi lib, or should they rely on globally finding them?
Would it be better instead of directly returning the dll library, return
a table with the library and additional extension interface, putting the
two above together? I dunno yet.
Dimiter "malkia" Stanev
On 7/31/11 10:35 AM, Duncan Cross wrote:
Should a module that uses FFI (but is intended to be used by
"FFI-blind" code) ever expose actual FFI-bound functions directly, or
should it instead wrap them in Lua functions?
The reason I ask is that it seems to me there are a couple of reasons
that you cannot trust FFI-bound functions to be passed around as
first-class values to arbitrary, "FFI-blind" code:
1. type(func) will be 'cdata', not 'function'. (of course, values that
try to make use of the __call metamethod already have similar
2. Perhaps more seriously, == or ~= comparisons that involve an FFI
function are very likely to throw an "invalid comparison" error, which
FFI-blind code will not be expecting.
...and maybe more that I haven't thought of. What do people think
about this? I am quite keen that only code that directly deals with
FFI should have to know any of the details of it, so this kind of
thing seems important.