From: guddt@uniwa.uwa.edu.au (David Bennett)
Subject: Re: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Organization: University of Western Australia
Date: Fri, 4 Sep 1992 13:42:12 GMT

beeman@cats.ucsc.edu (Adam Beeman) writes:
>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.

Yes...  So?  Your method is for saving memory...  Mine saves speed.

In your method it is MUCH more difficult to trap and redefine
modifications of variables.

>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 know the it isnt free.  The problem is in the game driver not the
style of programing.  The style I am advocating is nice too look at and
less prone to errors.  Yes, it is less prone to errors...  In the setup
function of your object you call

set_wieght(12);

It will pick it up...
call
set("wieght" 12); and it won't.

if you are doing thins with a set thingy, why not modify the driver to
handle change add in the fly global variable that auto-magicly create
set and query functions?  Seems more efficent to me.  If you are going
this way go the whole way, not half way.  In fact if you do this, remove
the concept of variable altogther.  You don't need them any more...  Add
a set_property and remove_property efuns.

What you are basicly doing in lpc is simulateing variables and
simulating their query and set functions.

>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.

Sure...  I may not be open minded.  I said in one of my other articles,
get on a moral high horse.  I am.  I quite often do.

>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.

I did in fact use this concept a bit in my mudlib, I use it for tempry
varibales and thingys that not every object wants.  It is quite useful
for this.  But...  For all the main things an object can do I would
still advocate using real variable and set/query functions.

>>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.

Yes....  Great...  so why bother with functions as well?  mke every
object just code.

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.