lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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.