On Jun 7, 2010, at 2:44 PM, Jeff Johnson wrote:
> On Jun 7, 2010, at 2:24 PM, Danny Sung wrote:
>> Actually I really like this idea. This would effectively introduce what could be a plugin architecture for popt. Ideally this should be done in a way where someone could create say an XML output and release a separate library called popt_help_xml or something.
> But the issue becomes
> Where do I get an additional "void *" from?
> in order to do
> rc = (*callback) (..., callback_context);
One can always hash up (or otherwise add a "helper" table)
to transform an integer back to an array, its called
"table lookup", taught in CS 102 (or at least used to be before Python
dicts and perl ties became all the Newer! Better! Bestest! rage).
An API cpuld be insturmented to retrieve Yet More Goop from the existing
"legacy compatible" 7-tuple table using additional "helper" tables and
Let's not go here _PLEASE_, my barf bag is already too close
to overflowing, and when it does overfloweth, yours truly has to clean up the mess.
But it is certainly possible to design API's for table lookup
pointer retrieval if absolutely necessary and deemed important
in POPT 2.0.
Personally, I think "incompatibility" in POPT 2.0 is less important
than designing in proper data structures that include an "obvious"
and "simple" means for a callback context pointer.
YMMV, everyone's does.
73 de Jeff
Received on Mon Jun 7 21:07:51 2010