Pondering a new parser a bit, I think it would be good to split
the existing command implementations:
1. A user interface function that takes the F_CMD_ARGS argument
list as it does now. Its tasks are:
a) To prepare a structure that contains the syntax tables for
the command and any context information that is necessary
to parse the commend syntax properly (example: The "last"
option of the WindowShade command is not always valid but
only under certain circumstances; the parser needs to know
about that).
b) To call the command syntax parser with the input structure
prepared in (a). The parser returns an output structure
describing the parse values and an error code.
c) In case an error occurs, the user interface function
generates an error message (if necessary).
d) If parsing was successful, the user interface function calls
the a command implementation function with the output
structure from the parser and selected information from
F_CMD_ARGS. To be specific, there is no information passed
that would allow the command implementation function to do
any parsing. The idea is that the interface function is the
owner of all information in the output structure, and if the
implementation function needs to store any information, it is
responsible to make a copy in allocated storage, if
necessary (or maybe just flag that it has taken posession of
the data?)
e) To call a cleanup function that frees all information in the
input and output structures. Hopefully this can be
automated.
Note: For these compatibility functions we have that just
translate the command line into a different command (e.g.
WindowFont is nowadays translated into a style command), the
interface function would pass execution to a different
interface function and not call the implementation function.
2. A command implementation function that:
* does the real work of the command,
* is passed only the information it needs to do its work,
* does no parsing itself
* can be called from elswhere without having to go through the
interface function
3. A cleanup function that frees any data allocated by the
interface function or the parser.
Rationale
---------
The split into interface and implementation can be started at any
time, independently of any new parser. It may be difficult for
some badly defined command syntaxes. The benefit is that we can
separate parsing from functionality and start writing a completely
new parser in parallel to the existing one. The old parsing could
be kept and be activated through a configure switch which would
just exchange the implementation of the interface functions.
Furthermore, the implementation function will have a well defined
interface allowing to call them directly from any other place.
In my eyes, splitting is an important step towards table driven
parsing.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
