They already have it, and they call it a header file.
Better FFI's generate their definitions from such header files, called header parsers. (based on some CPP code). This problem was solved in the 80ies, but I guess forgotten by now.
They already have it, and they call it a header file
Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.
What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).
That would have the benefit of:
(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.
(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)
(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).
Yup, there's also the more common approach of implementing extensions in C (or equivalent), possibly with an intermediate language.
For example, Cython is a much more scalable approach, in my experience, than attempting to describe the interface in Python and using a libffi-style binding.
True. I generate my dynamic API headers, code and test cases also automatically. In LibreDWG from some readable spec file. Because static code for 1000 of objects would be overkill. Unlike LiquidXML.
Comments
They already have it, and they call it a header file.
Better FFI's generate their definitions from such header files, called header parsers. (based on some CPP code). This problem was solved in the 80ies, but I guess forgotten by now.
Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.
What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).
That would have the benefit of:
(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.
(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)
(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).
(Article author here.)
Yup, there's also the more common approach of implementing extensions in C (or equivalent), possibly with an intermediate language.
For example, Cython is a much more scalable approach, in my experience, than attempting to describe the interface in Python and using a libffi-style binding.
The best FFIs generate even the C header files from a single parent source.
See: Vulkan's vk.xml
True. I generate my dynamic API headers, code and test cases also automatically. In LibreDWG from some readable spec file. Because static code for 1000 of objects would be overkill. Unlike LiquidXML.