Re: Circlemud design issues

From: Patrick J. Dughi (dughi@IMAXX.NET)
Date: 04/20/98


> >
> > Threading like this would be a huge break from the standard mud model
> > (ie, the way input is handled and so forth).  Major architectural
> > changes.  The question is, why?  Threads are nice, but they're not
> > going to magically solve all our problems.  In fact, quite the
> > opposite, synchronization will add quite a number of them.
> >
> > Further, if you read some on the Mozilla project, you see that
> > Netscape had to write their own threading library from scratch to sit
> > on top of all other OS's threads.  Is that something that really needs
> > doing in stock code?

        If it helps, when Mozilla er, netscape was developing their
 multi-threaded apps, there was no fully supported, fully working version
 of any sort of multi-thread libraries. Even today, most usable ones are
 under considerable development, as they have to cope with things beyond
 the simple and expected.  I think that you should not assume that any
 given idea will 'solve' all the 'problems' though - especially when the
 person who wrote about them did not even state such a ludicrious idea.
 Even more so when the difference in a problem is usually that of percieved
 needs.

> > Something I'm somewhat unclear on is who has the say on what goes in
> > where, and when things move along.  Jeremy mentioned opening Circle up
> > like a Bazaar-style development, and said something about a CVS
> > repository, but I never saw any followups to that.  Who is in charge
> > of the official distribution?  I'm assuming he is -- am I mistaken?
> >
        Jeremy is. George helps though, more than I think, Everyone else
 combined.  I'd read the archives, if I remember right, the location of the
 recent version(/under construction version) was there, but then again, I
 could be wrong. I was interested in it, but I had forgotten to follow up
 interest with effort.
>
> > Indistinguishable, yes.  But not an ubiquitous replacement.  The
> > reason for why is, suppose later someone wants to add code to let
> > people disguise and answer to different names.  A macro makes this
> > harder, and flow control less clear.  A function makes it very easy to
> > follow.  The macros work right now, but they're bulging at the seams.
> > They've been pushed too far, and are costing the Circle codebase a
> > great deal in terms of expandibility as well as readability.
>
        Truth to be told, the current macro set adds readability at the
 expense of nothing so noticable as expandibility.  I had the misfortune to
 code on a mud where the exact conversion you'd like had taken place.
 Instead of "GET_NAME(ch)" one had "GetName(ch)".  Instead of typing
 "struct char_data" one typed "CharData", etc.  You know what this did?
 Very little indeed. I actually had more trouble reading and using that
 code than I did any other sort - and considering I've been used to
 circle/diku and the like for about 5 years now, it came as a blow.  The
 macros, in my estimation, are simply short-hand for elements of commonly
 accessed structures (baring CAN_SEE.. I should re-write that one to a
 function).  Everything else is usually a simple if or value return.

> > typechecking when appropriate.  GET_NAME(obj) or GET_LEVEL(room) don't
> > make sense, yet the compiler, instead of spitting out an error about
> > invalid types, will complain about there not being certain fields in
> > certain types.

   If you can't figure out this error, you probably should't code. If you
 don't know enough about the system you're programing on to try to get the
 level of a room, you probably should examine the code.  And if you do all
 of the above, you'll still get an error pointing to the line of the error,
 and it takes seconds to fix.  I assume that a person would be just as
 likely to type GET_LEVEL(room) where GET_LEVEL is a function. Sure, you
 get a slightly more descriptive error message, but this isn't the sort of
 thing that would hold you up for more than maybe 10 seconds.  IMHO, its a
 waste of time to even argue about this.

> > What if it involves a table lookup?
>
        This seems nit-picky.  Say you have a race on your mud, and you
 can dynamically create races, with min/max values for strength, and this
 has an effect on the effective strenght of a character.. depending on how
 you design it, I'm sure you'd opt to use a table lookup - look how the
 ascii dynamic boards work.  Notice though, that in stock code, where
 boards are in an array, this can be easily accessed. Its all a matter of
 how you choose to code something based on what you need to acomplish.
>
> > > Also, this has a problem.  If ch isn't a simple variable, a function
> > will be called twice.  For instance, suppose nextSpellVictim returns
> > the next victim of a spell in a given room.
> >
> > GET_STR(nextSpellVictim());
> >
> > That won't work, because it will get the dex of the next victim,
> > and the con of the one after that.  Contrived example somewhat, but
> > macros have their limits, George.  They are headaches to maintain and
>
>       It is contrived. Macros aren't the end all be all of existance,
> they're literally shorthand. Creative use of macros makes code readable.
> They're just code, just like any other code (cept its preprocessed), and
> just as hard to mantain and expand as normal code. C'mon. This is starting
> to look more like an argument over 'The One True Coding Style'.
> > > Could do that in a macro too.
> >
> > Three-line macros, strung together with && and || are a headache to
> > maintain and deal with.  There is absolutely no need in modern
> > computing in these cases.  Circle is a mud, not a compiler, or runtime
> > interpreter.  Speed is important, but we're not exactly burning CPU
> > time as-is.  We can afford to spend a few more cycles for a more
> > robust, reliable codebase.
>
        I don't think that macros actually would affect (improve or
 worsen) running time.  They're pre-proceesed, just like has been said
 before. They're replaced with actual code.  Arugments for speed is a moot
 point.
        As for three if/and/or code, wouldn't you be duplicating that in a
 function anywway. Whats the big deal if its a function or a macro? Just
 make sure to include your backslash, and its the same thing.  And if a
 macro is already set up, wouldn't it be harder (20 seconds more) to turn
 it into a function than just adding another && IS_A_DEAF_MUTE(ch) to the
 end?  C'mon.

        Macros are useful, circle uses them all over because they're
 useful, though in most places if there is alot of processing, loops and
 the like, of course, we use functions.  In the end there's no difference
 thats worth even arguing over. Give it a rest.

> > Probably not... but the question is, what is the criterion for
> > something getting into stock code?  A lot of people like clans.  A lot

        Actually I'd like to know this too. I almost have a drop-in patch
 for race-allowing on a mud.  As I had said before, it dosen't change the
 behavior of stock code, but it does allow races to be easy to add, if one
 so wishes, as well as standardizing some of the more used race-affecting
 functions (regen time, fighting bonuses, innate abilities, class
 selection, etc).  Although I'm loathe to say that it is required, or even
 needed, at the same time, I can't come up with any useful arguments
 against it, baring that it works as expected.

                                                PjD


     +------------------------------------------------------------+
     | 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