Native FFI

[rauchg]

Essentially supporting https://github.com/node-ffi/node-ffi directly
(require('ffi'))

[seppo0010]

+1

[TooTallNate]

Definitely would eliminate a lot of the pain in users having to compile native addons (especially on Windows).

👍

[chrisdickinson]

+1 on this. Might be worthwhile to ask FFI maintainers from Python or Ruby if there's any pitfalls we should be aware of when bringing this into core?

[rauchg]

@chrisdickinson agreed. We could CC them on this thread even :D

[Qard]

👍

[chrisdickinson]

cc @arigo, who maintains Python's cffi package, and @tduehr, who maintains Ruby's ffi package. Are there any pitfalls we should be aware of before incorporating an FFI package into io.js core?

[piscisaureus]

(y) although can we put the feature behind a flag for some time?

[mikeal]

is this something we should get in to V8?

On Monday, March 2, 2015, Bert Belder notifications@github.com wrote:

(y) although can we put the feature behind a flag for some time?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[Qard]

How would FFI interact with V8, which is heavily template-based? I've only ever seen C FFI before. Is it even possible, or would we need that C abstraction over V8 that has been suggested several times before?

[TooTallNate]

How would FFI interact with V8

The same way it interacts with libuv (through C code)?

[tduehr]

@Qard you have it backward... V8 would be interacting with FFI.

I'm not aware of any implementation pitfalls, mostly because i didn't create mri or JRuby's FFI implementations. I can help with runtime pitfalls somewhat... You're going to want to give users a way to make objects backed by C memory structures to act as much as possible like any other JS object for allocation/deallocation purposes. For all other intents and purposes, interacting directly with the C call should carry C semantics. It should be up the the ffi user to implement more idomatic wrappers for their chosen library not a FFI implementation concern.

[arigo]

Hi there. Do you have anything more concrete to point me to? All I see is a vague question "what are the pitfalls of incorporating a Foreign Function Interface into xxx"... and I don't know what xxx is.

[Fishrock123]

See related io.js PRs: nodejs/node#1865, nodejs/node#1762, nodejs/node#1750

[arigo]

Probably not a useful note, but since you asked me: as maintainer of Python CFFI, I feel that if the goal is to call C code, then the interface should strive for the same simplicity as C itself. Ideally, if a feature doesn't exist in C, it is not part of CFFI either (reading big- or little-endian numbers comes to mind).

CFFI comes with a minimal API: the user writes ffi.cdef("some C declarations") to declare functions and types (using directly the C syntax), and then he uses ffi.new("foo_t *") or ffi.new("int[42]") to make a new C structure or array. You have a few operations on the "pointer" objects, like indexing and field access---and calls if they are pointers to functions. That's it for the core. This approach is completely different from Python's ctypes, even though it basically allows the same results.

(Another difference is the "API mode", a separate mode which produces C source code that must be compiled into a Python extension module; this has the huge advantage that you're working with C code at the level of C, including stuff like macros and structures-with-at-least-a-field-called-x; not at the level of the ABI. But this might not sell so well in the context of JS, for all I know.)