Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: [RFC PATCH] init_techs
Home

[Freeciv-Dev] Re: [RFC PATCH] init_techs

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Justin Moore <justin@xxxxxxxxxxx>
Cc: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: [RFC PATCH] init_techs
From: Daniel L Speyer <dspeyer@xxxxxxxxxxx>
Date: Sun, 23 Sep 2001 18:02:51 -0400 (EDT)

On Sun, 23 Sep 2001, Justin Moore wrote:

> 
> > >    If the command they entered was invalid, tell them so.  The command
> > > struct could easily be modified to facilitate a change by associating a
> > > function pointer with it.  Thus:
> > >
> > > typedef void (*command_func)(char *args);
> > >
> > > struct command {
> > >   char *name;              /* name - will be matched by unique prefix   */
> > >   enum cmdlevel_id level;  /* access level required to use the command  */
> > >   char *synopsis;          /* one or few-line summary of usage */
> > >   char *short_help;        /* one line (about 70 chars) description */
> > >   char *extra_help;        /* extra help information; will be 
> > > line-wrapped */
> > >   command_func *fptr;      /* Pointer to a callback function */
> > > };
> >
> > To allow functions that take a list, the command should have a content 
> > model:
> >
> > enum command_content {
> >    CMD_STR,
> >    CMD_INT,
> >    CMD_STR_LIST,
> >    CMD_INT_LIST
> > };
> >
> > Or something. Otherwise the callback functions have to typecheck their
> > arguments. If the parsing code typechecks, the callback functions can be:
> >
> > typedef void (*int_command_func) (int);
> > typedef void (*str_command_func) (char *);
> > typedef void (*int_list_command_func) (int, int *);
> > typedef void (*str_list_command_func) (int, char **);
> >
> > (For the list callbacks, the first function is the size of the list).
> 
>    Why?  Just pass everything that wasn't the command to the function.
> The overall framework doesn't need to know what each function takes.  Fx:
> 
> /set xsize 80
>  ^^^ ^^^^^^^^
> 
> /set attribute nation.Greek.techs Alphabet,Iron Working
>  ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> /easy
>  ^^^^
> 
> /hard Caesar
>  ^^^^ ^^^^^^
> 
>    The first part in each of these is the command.  The second part is the
> "char *arg" that gets passed to the function.  These callbacks should be
> content-oblivious, and it should be up to the specific functions to
> interpret the data correctly.

I agree here.  There may be functions which take a variable number of
arguments (e.g. /givetech nation tech1 tech2 ...)  If the command parser
tries to parse too intelligently, it'll just get in the way of
unanticipated syntaxes.

--Daniel Speyer
"May the /src be with you, always"


> 
> -jdm
> 
> "You don't give blood then take it back again
>  We're all deserving of something more"
>  - "Grievance"
> 
> Department of Computer Science, Duke University, Durham, NC 27708-0129
> Email:  justin@xxxxxxxxxxx
> 
> 
> 



[Prev in Thread] Current Thread [Next in Thread]