I've had a lot of ideas for cross-language libraries that would need a C API, and this issue always comes up. The idea I had several years ago---but never implemented, because most of the projects I'd use this for are in limbo because I never seem to finish anything---is an API with only one function, which takes JSON and returns JSON, possibly via JSON-RPC. Basically a library that pretends it's a remote service. Slow, yes, but not as slow as some alternatives, and it makes FFI setup with other languages easy.
lelanthran|2 years ago
I've done this one, and once only. I wouldn't do it again because the pain point is the lack of typing.
Yeah, yeah, I know, you've read all these blogs everywhere about how C is not type-safe, how C is weakly-typed, etc, but it's a damn sight better than runtime errors because something emitted valid JSON that missed a field, or has the field in the wrong child, or the field is of the incorrect type, etc.
If you're sending and receiving messages to another part of the program, using an untyped interface with runtime type-checking is the worst way to do it; the errors will not stop coming.
Every single time your FFI functions are entered, the function must religiously type-check every parameter, which means that every FFI call made has to now handle an extra possible error that may be returned - invalid params.
Every single time your FFI function return, the caller must religously type-cechk the response, which means that the caller itself may return an extra possible error - bad response.
Having the compiler check the types is so much better. C enforces types on everything[1], almost everywhere. Take the type enforcement.
[1] Unless the type check is explicitly and intentionally disabled by the programmer
CyberDildonics|2 years ago
ar-nelson|2 years ago