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

Reply via email to