Closed tsutsu closed 3 years ago
This is a common pattern in NIFs. The Erlang-side NIF module has to expose only the public functions that exist in the NIF itself. But the API surface of the NIF itself should be kept to a minimum, because it's harder to write/prove trustworthy code in a native language. So the usual solution is to create an Impl
module into which the NIF is loaded, which simply mirrors the minimal API of the NIF itself; and then to hide this impl module behind a wrapper module, that uses Erlang glue-code (rather than native glue-code) to safely decorate the API into a more usable form.
If you're asking about defdelegate
— it's strictly equivalent to just writing def foo(...), do: Module.foo(...)
. It just expresses intent more explicitly. (It also automatically defines functions for all arities the remote function is defined with, but that's not relevant here.)
Thanks @tsutsu! I'll approve and merge this, do you mind bumping the version to 0.1.3
and updating the Changelog ?
Sure, no problem
Hey @tsutsu, thanks for contributing! What's the benefit of delegating to the
Impl
module here ?