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

[Justin Moore <justin@xxxxxxxxxxx>]

> > > 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
> >  ^^^ ^^^^^^^^
>
> Every callback function that takes int must then do atoi and return an error
> message. The chances that the error message will be standardized is almost 
> nil,
> and it is more programmer efficient to do the atoi once, and let the
> programmers of callbacks assume that they are getting things in the right
> format.

   Return an error message how?  Have the function return a char*, or call
a fprintf-like function from inside the function?  Give the programmer a
standard way to return an error message (currently cmd_reply) and they can
customize error messages to their heart's content.  As a picky side note
atoi is bad; you should be using strtol so you can do error checking.

> > /set attribute nation.Greek.techs Alphabet,Iron Working
> >  ^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I hope that the syntax ends up being "set dotted.thing value", otherwise we
> have yet another set of callbacks to be maintained by the attribute callback.

   I don't particularly care about the syntax ATM.  But I would favor the
'attribute' tag since it could allow for further modularization of the
parsing code.  Otherwise you have to somehow parse out the dotted.thing
before even deciding on which callback to use.  And if we're using your
"we need different classes of callbacks", we'd need to parse out the
*entire* statement before figuring out what kind of callback to use.

> Again, if every callback has to parse its own string lists, some
> commands will accept "Alphabet,Iron Working" but not "Alphabet, Iron
> Working", some will want the list to be enclosed in quotes, some not,
> some will parse down to (Alphabet,Iron,Working) etc. The syntax for
> providing a list of strings and/or ints is an integral part of the
> ruleset/command language, and shouldn't be left to be invented by
> scores of different callback functions written by scores of different
> programmers.

   That's why we provide programmers with a standard, well-documented way
to parse data of ALL types, not just the ones we think are important.  We
make the tools flexible enough so they can do whatever they want.  We want
them working *with* the tools, not working *around* them.

> If we decide to go the untyped approach then we should at least provide four
> parsing functions that return int, char *, int *, and char ** and standardize
> syntax & error handling. I still think this is something that the framework
> should provide.

   We have standardized error handling through the cmd_reply function.
And what if I want to parse a float?  Or a float*?  Or a long, long*,
void*, or something else we haven't even thought of yet?  We leave them
trying to smash a square peg into a round hole.

> > These callbacks should be
> > content-oblivious, and it should be up to the specific functions to
> > interpret the data correctly.
>
> That way lies madness....

   And I maintain that your way lies scores of programmers that want to
strangle someone because there is only The One (or Four) True Way(s) to
handle this stuff.  IMHO, Perl is the best way to parse strings; I'm just
trying to give programmers a content-oblivious, Perl-like way to parse
incoming data.

-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