Re: Circlemud design issues

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

On Mon, 20 Apr 1998, James Turner wrote:

>That's not the answer either.  However, there is middle ground, and I
>feel I've reached it in my code.  It simplifies the above and makes it
>easier to follow what the code does.

What do you have so we may comment on it?

>It's more clear what the data actually is.  The struct makes it harder
>to follow, makes prototypes and declarations longer, and distracts the
>reader from what actually is being declared.

As was already said, it can make it harder to read.  I like to know that my
structure is a 'struct' and isn't yelling at me for no reason.  Data types
shouldn't be capitalized without regard.

>I can make ACMD's for things that aren't commands.  Just because it is
>declared that way doesn't mean it IS a command.  Call the functions

Just because I declare something to return 'int' doesn't mean it has to.
(See getc() for an example.)

You're arguing pedantically.

>do_* or cmd_* or whatnot.  As for changing the spells and commands --
>if your making the change in the structure just for one or two
>commands, you're probably going about it wrong.  If most commands will
>take advamtage of the changes, then you need to go into each function

But then you won't need to change those that don't use it.

>> Which is easier to maintain?
>Either that has the parameters clearly declared in the declaration and
>not hidden by a macro, though I prefer the latter.  Be honest, how
>likely are you to need to change the declarations without changing the
>functions themselves?  Besides,

Often, how many spells and commands actually use the command number?
Few, but some do need it.

>No.  A prototype generating script, or a sec script, will expand them
>in-place to proper functions.

Personally I turn on -Wmissing-prototypes and take the compiler warning.

>> I'm assuming you don't like CREATE() either then.
>CREATE is gone from my code also, replaced with void *mud_calloc(int,
>int).  It wasn't that difficult to replace all occurances in the code
>with proper functions -- five minutes work with emacs.

Although it's most likely uglier now.

>Not that much unnecessary casting -- it can be hidden with wrapper
>functions and thereby ensure type safety.  As for traversing a list
>given an arbitrary member, how often is that necessary?

You're given a person, find who is in the same room.

>> >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.
>The current arrangement is suboptimal (to put it mildly).  The weak
>inheritance would IMO be more efficient, more clear, and make it
>easier to expand later on.  Plus, there are way too many embedded
>structures anyway.

You're talking C++ again unless C has inheritance now.  Embedded structures
are not evil although I don't argue the current arrangement isn't the best.

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