[MUD-Dev] Re: Question on c++ switch optimization, and parsers in general.

[Mark Gritter]

Adam Wiggins writes:
> 
> I've always been fond of the simplicity of the "big array with everything
> you need to know about a given command" method.  Apparently some folks in
> the diku world are as well: I know that stock CircleMUD handles commands
> this way.
> 

One advantage of this approach is that it's easy to handle abbreviated
commands --- just change the strncmp() in Adam's code to be is_abbrev()
or whatever.  You can then choose the order of search so that, for 
example "n" finds "north" before "news", or "k" finds "kill" before
"kick".  I'm not convinced, however, that any order other than alphabetic 
is worth the confusion--- or that global support for abbreviated commands are!
(I generally find myself typing the whole command in, and individual-user
aliasing support seems more generally useful.)

What's also missing from this scheme, in my experience, is nice way of
dynamically changing what commands mean.  (In diku terminology, "spec_procs".)
In my mud (as in most Circles, I think) all commands go through three linear 
searches:
   -- list of aliases for the player (linear, exact search)
   -- call all spec_procs in the room, each of which generally uses a
      bunch of if...else if...else if... statements  (abbreviated search)
   -- list of global commands (linear, abbreviate search.)

Now... the profiler says this isn't a big part of our processor load, but
it still offends the perfectionist in me.  :)  I think it would be a big 
improvement to dump the abbreviation support (possibly adding the commonly
used ones to the global commands) and use three hash tables to do the
lookup.  (Or at least B-trees.)  But... it might be interesting to study
whether the cost of updating the data structure as mobs and objects move
around is greater than the benefit obtained in verb lookups.

What this reminds me of is method dispatch in Smalltalk or Objective-C,
where the object has to determine at runtime how to dispatch a method.
Unfortunately, I don't recall how this is implemented, but it seems like
the aliases-specials-globals hierarchy is similar to inheritance--- except
that it can change at runtime.

Mark Gritter
mark at erdos.stanford.edu