On Sun, 19 Apr 1998, James Turner wrote:
>However, I think there is also room for higher level discussions.
Of course, I have plenty, and there's room for world discussion too.
>It really is an excellent code base, but I think it, like any other large,
>multi-generation project, has some questionable design issues that have
>long since needed rennovation.
Kind of like how the four global buffers absolutely kill multithreaded
potential? :)
>I'd like to see a discussion on these topics, which are
>probably too drastic for changes in the 3.0 codebase (maybe 3.1, or
>perhaps 4.0).
I do occaisonally, don't get many responses except when people miss the
point of the project.
>1. The biggest issue in my opinion is the use of macros. Macros
>definitely have their place, but computer speed has increased so much
>since the first circlemud that they become less and less of a speed
>issue.
Macros are nice for other reasons. They can do cheap checking like I have
done in the upcoming bpl13 code. Everything that now references a player
specific structure element will produce a warning when used on a mob.
>Moreover, their inherent nature makes it very difficult to
>debug in some circumstances (particularly since you can't set
>breakpoints in a macro, and because expansion can be different than
>you would expect and there's no way to see the problem without running
>the code through the preprocessor).
You shouldn't do that much in a macro then. The only real offender is
REMOVE_FROM_LIST, which is there for obvious reasons.
>Additionally, it would be nice if a higher level of data abstraction could
>be reached; macros provide useful hooks to such things (replacement with
>functions, then renamnig all occurances via sed), but they aren't enough.
They are also there for structure variable abstraction, data checking, and
readability. GET_NAME(ch) or ch->player.name? How about GET_SAVE(ch, i)
versus ((ch)->char_specials.saved.apply_saving_throw[i])?
>(Additionally, for speed issues, gcc allows for the inlining of
>functions, even in C code. Perhaps VC++ provides a similar facility,
>but with the progression of Cygnus' gnuwin32 [which I am assuming
>supports inlining like this], I see less and less need to explicitly
>support such an alien compiler).
GCC will automatically inline functions if you use -finline-functions or
-O3.
>2. Expandability. Circlemud provides a great platform for newbie
>admins who just want to start a mud. But in some respects, it is
>difficult to expand. For instance, the skill code is rather
>restrictive IMO.
Already scheduled to be rewritten.
>In my current code I've replaced this with a more
>robust and flexible set of code.
My rewrite will be akin to what the magic system rewrite was.
>Similarly, I've done the same with ability scores (a smaller project, not
>needed in many cases, but it has its uses to abstract them as well).
Huh? Isn't GET_STR(ch) abstract enough?
>Guild code is something that Circle could use (by this I mean part of the
>main distribution) which isn't trivial to add.
It has guild code, see SPECIAL(guild)
>3. Layout. The code in circlemud is, to be honest, poorly laid out.
It inherited from Diku.
>The file divisions are usually fairly accurate, though there are many
>contradictions and oddities in the code that make it hard to understand
>what functions belong in which files. I personally use Emacs and etags,
>so this is much less of an issue, but it is still a design issue that
>needs addressing. Also, we need a single .h file; having several is a
>real problem.
A single .h file would cause excessive recompilation.
I can understand the argument with conf.h, sysdep.h, structs.h, and utils.h
though, since everything already includs them.
>home/P-T/saga/saga.alias
>home/P-T/saga/saga.objs
>home/P-T/saga/saga.skills
Everyone has a different opinion, although I don't entirely disagree with
that.
>Yes, there is a tiny amount of redundancy in the name appearing twice,
>but it makes backing up easier, as well as removing a single player's
>files, renaming them, etc. Further, it eliminates issues of having
rm */*/player.*
(Would erase 'P-T/saga/saga.*' in your example.)
>low level string functions, for instance, have several functions doing
>similar tasks.
Like?
>6. Code appearance. Circle is in most cases readable; however, there
>are times it isn't. In particular, the use of typedefs can simplify
>things.
Working on some... (room/mob/obj/etc types) Feel free to suggest more.
>Also, we need to get rid of ACMD and ASPELL (something I did straight
>off). They are a convenience in the initial writing of a command or
>spell, but they are an abuse of notation, so to speak, and can cause
>problems with symbolic debuggers as well as cross referencing programs.
They are quite handy to figure out what is a player-visable command and
what isn't. I'd say fix the debugger or cross reference program.
>Generally, for every time you're lazy when you
>code something, you'll spend three hours later fixing a shortsighted
>mistake or some other issue ;)
I work hard to be lazy. In other words, if I can make a script to automate
some task I do all the time, I do. I wouldn't call ASPELL() being lazy,
it's definitively declaring what the function is, and what arguments it
gets. The spells and commands would not work if they took different
arguments. (function pointers)
>Also, it would be nice if all the code conformed to one style. I have an
>indent script I use for my own (though I don't need it often since I let
>emacs do my formatting for me) which reformats all the code to a specific
>style. It's quite useful.
Most of it was formatted with the following 'indent' parameters:
-kr -i2 -di0 -npsl -nfc1
(Saved the mail message where Jeremy said that, you can find it somewhere
in the mail archives if you don't believe me.)
>7. Linked lists. The current linked list support is, well, somewhat
>dirty. Imbedding next elements into all the structures then using the
>REMOVE_FROM_LIST macro is extremely ugly. We need to get a simple
>linked list library written (a fairly simple task), or use one out
>there.
You don't have to use 'next', you can name it whatever you want. The
REMOVE_FROM_LIST is simple and works, especially considering you cannot use
a function and this is not C++.
>I personally use the singly linked list class from glib (a
>subcomponent of gtk, which provides a large amount of common C
>algorithms and structures, including hashes, lists, and I believe
>trees), which is exactly what we need. The only downside is that,
>though glib itself is cross-platform I believe, gtk probably doesn't
>port to Win32 yet.
CircleMUD is a base, not the end-all-be-all MUD.
>Okay, that's it for now. I hope no one construes this as any kind of
>flame -- I am a big circlemud supporter (I wouldn't be coding one if I
>weren't). But we need to think about the future.
Criticism is good.
--
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