From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Date: 3 Sep 1992 19:46:37 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: mingong-ws-4.ucsc.edu


In article <1992Sep3.112652.6641@uniwa.uwa.edu.au> guddt@uniwa.uwa.edu.au (David Bennett) writes:
>beeman@cats.ucsc.edu (Adam Beeman) writes:
>>Notice all the set_* functions? what a waste... unless you like typing
>>set_this_silly_variable(value) a lot.  I'm in the process of doing away
>>with most of this.  In my system a single pair of functions, set() and query()
>>can deal with quite a lot of this stuff.
>
>On the single set/query idea...
>I dont like it...
>
>It is much easier to loose things.  One problem I had with changing
>somethings to mappins in my code (and craig already outlined) was my
>terrible spelling.  Using this method for setting and querying the
>variables is very prone to this error.

Seems to me that writing a mudlib in general is very prone to this error.
I'm not convinced by this.

>The only useful reason for using
>this syntax is the way that functions are done in lpmud creaing a large
>table.  Fix this, don't hack your code.  There is nothing elegant aout
>this style of programing.  In fact quite the reverse.

So you would create two functions for each variable?

int foo;
void set_foo(int i) { foo = i; }
int query_foo() { return foo; }

Now, every object that inherits this gets these functions, and eventually we
have about 50-100 accessor functions like these in the player object alone...
possibly many more.

I would not eagerly seek out people and tell them to use your style of
programing unless inherited functions were totally free, which they aren't.
Check out the difference in memory usage between two functionally identical
objects, one of which clones a file and configures it, and the other of which
inherits the original and then configures itself in create().  It's a pretty
significant difference.

>I feel it looses clarity and makes the code harder to read (as well as
>makeing it more prone to silly errors).

Actually, I think since you're used to your way and not totally open minded 
about mine, you assume that it would be harder to make sense of.

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.


>In fact.  why have functions at
>all?  Make them all done in one function called function with a huge
>switch statement in lpc with mapping everywhere.  Uses much less
>overhead for every object.

Now you've come full circle to what I've already done.

>
>David.
>[DDT] Pink fish forever.
>-- 
>  David Bennett,  guddt@uniwa.uwa.oz.au | University Computer Club
>     Where Pink fish swim backwards.    | c/o Guild of Undergraduates
>These words I am singing now mean nothing more than meow to an animal - TMBG
>Disclaimer: Any spelling mistakes in this article are all entirly my fault.  Any grammer errors spotted in this article were put there because I could.

Adam
Sometimes Buddha@TMI
-- 
#include <std/disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus