On Jun 13, 2010, at 3:30 PM, Jeff Johnson wrote: > > todo++ still early yet for POPT 2.0 >
Well after some thought, I believe that a RPN calculator (nominally dc(1) syntax with changes as needed) will help eliminate the litter of data typing that POPT has accumulated over the years. E.g. POPT has methods/types for all the usual int/short/long/longlong/float/double data types without any clear abstractions. All that's needed is coercion when import/exporting option values from an application. These days an internal int64_t (or uint64_t, signedness with bit operations is mostly useless and I don't expect much of a usage case for a RPN calculator in POPT). The one notable exception is RPM, which uses POPT quite extensively for parsing not only CLI options, but also config/macro values. RPM usage of POPT was what caused methods like poptSaveInt() et al to be added. But I can easily change those interfaces @rpm5.org at will and the need(s) of RPM have changed over the years so that, say, parsing Berkeley DB configuration for an rpmdb just isn't important any more (has never really been used/useful afaik). For discussion purposes, assume 1) an RPN calculator implementation for binary arithmetic operations. 2) the RPN calculator stack is initialized with 2 values (I'll call the values "X" and "Y" while describing) 3) The "X" value is pushed first and is essentially the "option value", either --foo=1234 or through the pointer in the 4th field of the table 4) The "Y" value is pushed second from the integer (and eventually long/ptr) from the 5th field of the table. 5) The RPN "program" (i.e. same as you would type to dc(1)) will come from the argDescrip 7th field in the table. That's enough of a convention for me to re-target RPM calls into POPT and eliminate most of the type-based methods like poptSaveInt() in POPT. I'll wire up the RPN binary arithmetic while muddling how strings and bit masks/sets (more useful for POPT) could/should be added to a RPN calculator abstraction. The next goal will be to attempt a per-item (not per-table) callback signature. For the short term, I'll assuma as starting point a no-brainer int main(int argc, char ** argv[]) calling signature and extend with POPT/application context arguments as needed. 73 de Jeff ______________________________________________________________________ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org