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
>functionality.
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:
ASPELL(spell_create_water)
{
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)
{
Hmm...
or
void spell_create_water(int level, CHAR_DATA *ch, CHAR_DATA *ch, OBJ_DATA
*obj)
{
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 - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST