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