[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] Re: getopt() as gtroff macro ?
From: |
Keith Marshall |
Subject: |
Re: [Groff] Re: getopt() as gtroff macro ? |
Date: |
Fri, 24 Sep 2004 04:36:04 +0100 |
On Thursday 23 September 2004 7:56 pm, Steve Izma wrote:
> Hmmm. I now realize I didn't think this through completely before
> replying last time, so it's now more apparent to me what Keith
> was doing.
>
> I like python's facility for this, but one reason, I think, that
> it works so well is because of how easy it is in python to step
> through a list, so that you can set up a "while" loop and step
> through each option and write the appropriate code for each one,
> if it's present. I would prefer to avoid calling outside macros to
> process the options and instead just be able to set flags and
> variables.
Indeed. My sample macro code -- which was derived from actual working code
-- was designed to simulate the behaviour of a 'switch' within a 'while' loop
in C code, (which is how option parsing is C is traditionally handled with
the getopt() function), and my option handler macros providing the 'case'
implementations. I don't know Python, but I assume its getopt module
operates in a similar fashion.
> How about having getopt set local variables based on the option
> names, both the long or the short ones (one could choose between
> readability and conciseness). Flags would always
> be numeric (essentially boolean) and options with values would
> always return a string, which if numeric would require a unit
> designator [...]
Thinking about this, I believe it should be feasible, and may indeed offer a
better and more robust implementation than requiring the user to provide call
back macros. Using macros certainly offers greater flexibility; however it
also places an additional burden of initialisation on the user. By
stipulating that flags are always returned in registers, and option arguments
are always placed in strings, we can handle the initialisation in a
consistent manner, and the user is assured a consistent API to the .getopt
request.
For initialisation, I would suggest that all possible flag registers are
defined with zero value, and all possible option argument strings are either
guaranteed to be undefined, or, perhaps preferably, are defined with zero
length, prior to parsing the argument list.
I do believe that the user should be required to provide two call back macros
-- one to handle the case of parsing an undefined option, since IMHO the user
*needs* to be able to choose the appropriate action, and the second to
process the arguments which remain, after the options have been stripped.
I think this second used supplied macro should also be required to perform
*all* of the user defined processing which requires access to the flags and
strings set by .getopt, thus allowing .getopt to take the responsibility for
removing these flags and strings from their respective namespaces, on
completion.
As a final observation, if both long and short options are declared to
control the same function within the user's call back code, then the user
must explicitly take responsibility for interpreting both forms equivalently.
I can see no reliable way of handling this implicitly, within any .getopt
implementation.
Best regards,
Keith.
[Groff] Re: getopt() as gtroff macro ?, Steve Izma, 2004/09/23
Re: [Groff] Re: getopt() as gtroff macro ?, Keith MARSHALL, 2004/09/24
Re: [Groff] Re: getopt() as gtroff macro ?, Keith MARSHALL, 2004/09/24