Alternative proposal (was Plugin project proposal)

[Nicolas Williams]

On Wed, Jul 21, 2010 at 11:57:12PM -0400, Greg Hudson wrote:
> I want to acknowledge the effort you put in here and give some context
> about our internal decision process, which I realize has been dragging
> on.

Thanks.

> I also read your sketch carefully.  The main significant aspect I noted
> is that you use macros to auto-generate the declarations and what we
> would call the "consumer API" for each pluggable interface.  That's
> laudable in the sense of minimizing how much raw code needs to be
> written for each pluggable interface, but as a matter of development
> culture, I think we want to move away from using complicated macros to
> create code, even if it sometimes means writing more code which looks
> similar to other code (and certainly more code than you're write in a
> language with higher-order constructs).

Actually, no, that's not the key to my proposal in my view.  Code
generation is certainly an important aspect of my proposal, but the key
is elsewhere.  The key lies in the generic framework's functions and,
most importantly, its plugin entry point lookup and invocation macros.

In fact, I included the code generation aspect of my proposal as a way
to show how one can come up with a genric, instantiatable design that is
not unnecessarily complex.  But the part I consider key addresses an
altogether different issues: strong type safety.

Additionally, I was addressing all the salient concerns expressed by
Zhanna and others while also remaining neutral on the dlsym-one-at-a-
time vs.  v-table interface approach.

> My own reason for this preference, which I've already briefly mentioned,
> is ease of debugging.  If something goes wrong anywhere near a piece of
> automatically generated code, it can be hard to step through it and
> understand what's going on if you don't work with that code regularly.
> The generated code itself may be 100% correct, but maybe you're passing
> it invalid arguments which causes a crash, or maybe the generated code
> is invoking other code in which something goes wrong.

We've often checked in rpcgen-generated code for similar reasons.  Code
generation need not imply that code is generated every time the code is
built.

> Not every code generation mechanism is equally harmful in this respect.
> I find macros to be the worst offenders, since the generated code does
> not exist in any file unless the developer goes through extra effort to
> save the preprocessor output, and even after that the output is
> typically very hard to read.  On the other end of the spectrum, code
> generated by rpcgen is (1) typically present in the build tree, if you
> have a build tree handy, and (2) pretty easy to read.  In the middle are
> tools like yacc, which (of necessity) create code which is pretty hard
> to understand, but at least it's there in the build tree.

In this case the macros I proposed are extremely straightforward --
extremely so, in fact, if you drop any notion of required vs. optional
plugin entry points, so much so that you might simply drop the code-
generation macros and adopt the style of the code they generate.  As I
mentioned, the more involved the code generation, the harder it is to
use cscope.  But if you include the results of that code generation as
cscope inputs (e.g., by putting under version control, with suitable "DO
NOT EDIT" warning comments) then that problem goes away.

Note that I reviewed the project page and the e-mails posted here.  I've
not reviewed the prototype you mentioned in this last e-mail.

Nico
--