From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Accessing attributes (was: Re: Virtual Rooms and Objects)
Date: 4 Sep 1992 06:24:32 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <KJETILHO.92Sep4023048@holmenkollen.ifi.uio.no> kjetilho@ifi.uio.no (Kjetil Torgrim Homme) writes:
>In article <185q2tINN59v@darkstar.UCSC.EDU> beeman@cats.ucsc.edu (Adam Beeman) writes:
>   however, compare:
>   set_foo(value) with set("foo", value). If you know what set() does, you will
>   know that all this is doing is setting a variable named "foo" to a given 
>   value.  You don't have to check and see what set_foo() does in addition to
>   this.
>
>Pros:
>  - the objects look more clean without all those set_* and query_*

Not just cleaner... much smaller, too... I've been cutting the sizes of many
things almost in half since I started doing this.

>  - you can have more functions for each variable: add(), remove(), in() to
>    maintain a set.

So far I have set(), query(), add(), and delete().  Others I might need?

>  - you can make a tree structure of the variables, ie.
>    set("property>>visibility", 50)
>

Already implemented.  In my system, you can have nested mappings, up to 3 
levels deep... and access any part of them with any of the accessors.
My way of doing it is using the "/" to separate things... so you can:

set("wealth/gold", 100);

and access the "gold" index of a mapping called "wealth".

>Cons:
>  - you can get lots of stray variables (from typoes or misuse)

yeah, people make typos... I'll make a static, minimalist version for
temporary properties and encourage people to use it... it'll help.

>  - in a trivial implementation, security is non-existant

My implementation isn't trivial.  Want an object to start checking
security?  Do ob->secure()  to enable security.  There are several levels of
security on variables thus far:

	public - anyone can do anything to these variables
	read-only - only the owner and master can change these, all can read
	owner-only - only the owner can read these or change them
	master-only - only the master euid can change these, all can read
	locked - once set, it can never be changed
	private - only the master euid can read or write these variables

These are set with either a third arg to set() or with set_mode().
There's a file, priv.h, that defines these all as bitmasks.

>  - if you want to redefine the interface, you'll have big problems
>  - problems with variable name clash
>

These two are problems with any software design project.
Hopefully I've put enough time into this to get it right, and won't need
to change it much more.  If we make good notes about "reserved" variables,
then that'll be a big help.  Also, the creation of a static, minimalist
set for properties will resolve a lot of this, since they don't save when
you quit.  I liked Darin Johnson's suggestion of prepending the wizard's 
name to a variable.

> [ mudlib code deleted -- implementation is trivial ;-) ]
>
>I don't think name clash will be a great problem. It is after all the
>coder of the mudlib's responsibility to ensure good and fitting
>variable names, and to keep them unique shouldn't be a problem. If the
>concern is that wizards may use variable names that the mudlib may
>annect later, well, then this system is none different in that respect
>from the traditional set_* and query_* method.

I agree with this absolutely... I went nuts one day installing some code
from pinkfish for pluralizing stuff, and suddenly aliases broke... lo and
behold, his hacked up Object.c had a query_aliases() that was overriding 
the one in the player object.  It took me a while to find this, I kept
wondering how the aliases had turned into an array from a mapping. ;-)

>
>
>Kjetil T. (aka Tenghil)
>
>PS. I first saw the idea about using one mapping instead of lots of
>variables on TMI. Great concept, Buddha :)

Thanks... the only problem with it, is that you can no longer edit someone's
.o file by hand unless you use an editor such as emacs, because the mappings
are very long strings that most editors cannot handle.  This can cause problems
if someone takes a player save file into ed, but it prevents frobbing
attempts because if the save file gets corrupted it can be thrown away. ;-)

BTW: I almost posted code for this, but it's long, convoluted (but efficient),
and I didn't know if it would be a waste of bandwidth... it's also not totally
done or debugged yet, and only runs on MudOS... so it might scare off some
2.4.5 people from LP's entirely when they see the future... ;-)

If there is suitable demand I will post code.

-Adam
From time to time people call me Buddha@TMI


-- 
#include <std/disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus
Newsgroups: rec.games.mud.lp