On Jun 7, 2010, at 12:20 PM, Wayne Davison wrote:

> On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson <n3...@mac.com> 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.

(aside)
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
        -lpopt
to change to
        -ljdod
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.

(aside)
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

Reply via email to