[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
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the mud-dev-archive mailing list