Re: [Gnucap-devel] Gnucap commands and their interface

[al davis]

On Thursday 03 May 2007, Xavier Romeuf wrote:
> However, they could be found by asking the dispatcher which
> of them are currently installed, once Gnucap is started.
> Would you mind adding some members to the DISPATCHER class
> which return the mapped commands (DISPATCHER::begin() and
> DISPATCHER::end() for instance)?

Good idea.  Easy, done:

template <class T>
class DISPATCHER {
private:
  std::map<std::string, T*> * _map;
public:
  typedef typename std::map<std::string, T*>::const_iterator const_iterator;
  const_iterator begin()const {assert(_map); return _map->begin();}
  const_iterator end()const {assert(_map); return _map->end();}
.......

A warning ...   This will include entries for failed lookups, as an artifact
of the way std::map works.  "first" is the name.  "second" is a pointer,
which will be NULL for a failed lookup.  This can be taken care of by
defining a new class const_iterator instead of using a typedef, and
the operator++ and others skip the NULL entries.  I didn't do that yet.


> Another improvement of the commands could be a descriptor:
> how about adding to each class derived from CMD a member
> function which tells what it does? A possible way would be to
> return a simple string describing the command and its
> parameters, or, even better, a map, each value of which would
> be the description of a parameter.
>
> Thus, each command would be smartly defined: its
> implementation (CMD_XXX::do_it()) and its interface
> (CMD_XXX::get_description()). It may also be interesting for
> a future "help" command.

I thought about it, even before you mentioned it.  I agree that
something like that is needed, but there are too many questions
now to jump in.

After starting a trial implementation, and tripping, the thought 
came to mind that it would be better to just pass the string "help"
to do_it().

But in a hidden way, you asked for something else ...  The new function
that you called get_description() would return an object containing
a description (probably a std::string), not print it.  You could then 
use it the way you want.  A "help" option on the command could call
it to get the description.  The argument (either a std::string or CS 
object) could be used to refine the request.  The base version could 
have some kind of default action, like searching a file somewhere.

So far, that is easy. 

The difficult (time consuming) part is to write all those descriptions,
and keep them in sync with the manual and actual code.
Keeping the manual in sync is already a problem.

Ideas????