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 methods. 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 ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List [email protected]
