Re: Circlemud design issues

From: George (greerga@CIRCLEMUD.ORG)
Date: 04/20/98

On Mon, 20 Apr 1998, James Turner wrote:

>> >low level string functions, for instance, have several functions doing
>> >similar tasks.
>> Like?
>char    *one_argument(char *argument, char *first_arg);

Gets one argument, ignoring fill words.

>char    *one_word(char *argument, char *first_arg);

Gets one argument, honoring quotes, ignoring fill words.

>char    *any_one_arg(char *argument, char *first_arg);

Gets one argument regardless.

>char    *two_arguments(char *argument, char *first_arg, char *second_arg);

Simple extension of one_argument.

>void    half_chop(char *string, char *arg1, char *arg2);

Simple extension of any_one_arg to allow arbitrary number of arguments.

>Five functions (at least) for doing more or less the same thing.  This

They more or less build on each other to do different things.

>can be reduced to two or three functions which provide more robust

You could use arguments for differing functions:

snip(argument, result, S_NOFILL | S_QUOTE);

But that would result in one unreadable function as opposed to many smaller
functions that have a very defined purpose.

>I've done so in my code and will post a snippet if anyone would like
>(basically I have a function that splits a string into words, optionally
>respecting quotes and double quotes, and stores the results globally).

globally?  Speaking of threads...

>I've got OBJ_DATA, CHAR_DATA, ROOM_DATA, etc.  I believe Envy uses the
>same naming scheme.  I have a sed script I've used to replace my
>code's references to the full 'struct char_data' names that I would be
>glad to give you if you're interested.

Again, I don't see the advantage besides saving the 'struct' typing.

>I agree, fix the other programs.  However, using ACMD and ASPELL are ugly.
>They redefine the language and its grammar.  They obscure the true
>declarations.  Preprocessor macros weren't meant for this kind of thing.
>Now, admittedly, my objection stems from a language purist's point of
>view.  But we shouldn't bastardize the language unless we absolutely
>have to.  Using the full declarations is no huge strain :)

You lose:
* the distinct identifier that the function is a spell or command.
* time because you have to change 30 spells (or 100 player commands) when
  you need a new argument.

If people cannot tell:

is a function, then I pity them. ;)

void spell_create_water(int level, struct char_data *ch, struct char_data
*victim, struct obj_data *obj)



void spell_create_water(int level, CHAR_DATA *ch, CHAR_DATA *ch, OBJ_DATA

Which is easier to maintain?

>I once read somewhere the definition of a good programmer is one who
>knows just how lazy he can be without breaking something.  Laziness is
>a time-honored tradition among programmers, one that I subscribe to
>fully.  I should have added the word "unnecessarily" up there :) ACMD
>and ASPELL hide the declarations and change the grammar of the
>language.  I'm not saying change the definitions, or let some commands
>take different parameters.  I just mean that we shouldn't use macros
>like this.

I guess you'd like to type that huge block of prototypes out in
interpreter.c then?

I'm assuming you don't like CREATE() either then.

>I'm saying don't have _any_ pointers like next in the structures.
>Instead have a linked list library using structures like
>struct ll_data {
>  struct ll_data *next;
>  void *data;

Lots of unnecessary casting, small objects to increase memory usage by
alignment issues, ugh.  Then you cannot traverse the list when given a
structure because it doesn't have a reverse pointer to itself in the list.

>struct char_data {...};  /* character data common to players/mobs */
>struct player_data {
>  struct char_data ch;
>  ...
>struct mob_data {
>  struct char_data ch;
>  ...

From structs.h:
   struct char_special_data char_specials;      /* PC/NPC specials */
   struct player_special_data *player_specials; /* PC specials */
(*)struct mob_special_data mob_specials;        /* NPC specials */

(*) - Could be a pointer though.

George Greer  -   | Genius may have its limitations, but stupidity | is not thus handicapped. -- Elbert Hubbard

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | |

This archive was generated by hypermail 2b30 : 12/15/00 PST