Re: [LuaJIT FFI] Recommended policy for exposing FFI functions
Dimiter "malkia" Stanev <malkia <at> gmail.com>
2011-08-01 08:25:46 GMT
Hi Duncan,
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
some point:)).
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
possibly others).
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.
Thanks,
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
> problems...)
> 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.
>
> -Duncan
>
>
RSS Feed