[MUD-Dev] Naming and Directories?

Mark Gritter mark at erdos.Stanford.EDU
Sat Mar 13 23:18:32 CET 1999

Chris Gray writes:
[description snipped]
> I tend to use the tables much like scopes in programming languages. For
> example, some of the more basic symbols needed in the scenario are put
> into table "t_base". There are also "t_util", "t_fight", "t_icons",
> "t_graphics", "t_build". When an "area" (no formal definition) is
> built, I tend to put all of the symbols (room-names, local function
> names, special object names, etc.) into that table.

Very interesting!  This goes farther than I was thinking of, since it looks
like many different sorts of objects (both "in-game" objects like
a shovel or "background" objects like properties) are combined in the
same namespace.

Do you allow aliasing?  Could I set up a private directory which contained
name->object mappings for objects which I did not "own", or is the mapping
more strictly scope-like?

> This scheme works reasonably well, but has the expected problem of
> not knowing where to look for a symbol when you get a large number of
> symbols. When I do things like tracebacks on run-time errors, I look
> in all "in use" tables for definitions for symbols encountered (e.g. as
> function parameter values) during the traceback. This is most useful
> when a programmer is testing code and has all the needed table "in use".
> However, I had to add a SysAdmin-only builtin that searches all tables
> in the system (doing a recursive search) for all names for a given
> value. This allows SysAdmin to find out who owns something, or to find
> his own stuff that he has forgotten about. It puts a fairly heavy load
> on the server, however, which is why only SysAdmin can use it.

It sounds like even this more limited ability was useful, though.  It doesn't
seem possible in your system to "lose" an object or have anonymous objects---
which I think are useful properties to have for debugging.

Mark Gritter
mgritter at cs.stanford.edu

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list