[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Oddities with dynamic modules

From: Philipp Stephani
Subject: Re: Oddities with dynamic modules
Date: Thu, 21 Mar 2019 21:32:07 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]