On Jun 7, 2010, at 12:20 PM, Wayne Davison wrote:
> On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson <firstname.lastname@example.org> wrote:
> And without some deterministic way to tell whether its a POPT 1.x <-> 2.x
> table being fed to the POPT API/ABI, well, only a deliberately
> "incompatible" POPT 2.0 data structure with some deterministic
> version identifier is possible.
> One way to deal with this is to change the library name to "popt2". That way, a popt (1.x) using program would never get run with a popt2 library.
OK, let's go down that path ...
Assume I change the name of "popt" to "jdod" (ASCII art upsidedown and reversed to make a point)
What "compatibility" problem is solved by renaming?
Doesn't fiddling the loader map to change the symbol versioning
achieve "incompatibility" a bit more transparently.
Eeek, no symbol versioning in existing -lpopt, time to fix that with popt-1.17, todo++.
The added tyrrany of forcing every application that currently has
to change to
will be rate-determining to adoption (and glacially/tectonically slow imho)
So slow that it may not even be worth the effort of developing and releasing POPT 2.0.
That too is an option.
There's no easy answer and I'm deeply conflicted, but am being encouraged
to attempt a POPT 2.0 release to "fix" certain issues like --help. Go Google Rusty Russell's
POPT code review. He (and I) want to see callbacks used, and a callback
paradigm Done Right forces a "void *" context pointer like this (AFAICT)
int rc = (*callback) (...., void * callback_arg)
which means that I either
1) overload the i18n field pointer(s) with Yet Another Obscure Overloading (the
per-table pre- and soit- and post- callbacks are already quite tricky to use correctly)
2) add another pointer field to avoid overloading and introduce "instant incompatibility"
I can go either/both/neither way. My interest is in useful and simple software, nothing more.
Again, I use "jdod" just to illustrate why renaming to -lpopt2 is just the tip of a large iceberg.
(you know that already).
73 de Jeff
Received on Mon Jun 7 18:41:29 2010