Re: [LuaJIT FFI] Recommended policy for exposing FFI functions

["Dimiter \"malkia\" Stanev" <malkia@...>]

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