Re: Oddities with dynamic modules

[Philipp Stephani]

Am Do., 21. März 2019 um 21:17 Uhr schrieb Eli Zaretskii <address@hidden>:
>
> > From: Philipp Stephani <address@hidden>
> > Date: Thu, 21 Mar 2019 21:04:07 +0100
> > Cc: Eli Zaretskii <address@hidden>, Emacs developers <address@hidden>
> >
> > > > I thought simplicity and convenience of use tramps simplicity of the
> > > > implementation, so it is strange to read arguments to the contrary.
> > > > IME, inconvenient interfaces are the main reason for them being
> > > > unstable, but that's me.
> > >
> > > A good middle ground is a minimalistic (but sufficient) API at the
> > > host side, plus idiomatic convenience wrapper libraries for each
> > > client language. (The latter need not be maintained by the host API
> > > maintainer.)
> >
> > Yes, that's exactly what Daniel suggested in his initial design. It's
> > also what largely seems to be happening: people have written idiomatic
> > wrappers for Rust, Go, and probably other languages.
>
> Where's the wrapper for C?

It seems like there isn't enough interest in modules written in C for
such a wrapper. Or there is a wrapper and I just don't know about it.
The module API is usable as-is, and writing and maintaining a wrapper
is nontrivial work. For other languages wrappers are necessary, but C
users can use the plain API directly, and that's often a reasonable
choice. For example, the FFI module
(https://github.com/tromey/emacs-ffi/blob/master/ffi-module.c) is
complex enough that a wrapper library probably wouldn't make it much
shorter.