Subject: lexical scope of dobj, player, etc

From: [email-masked]
Date: Tue, 30 Nov 1993 12:27:25 -0800

Wow!  I hadn't realized that you can just set the value of dobj in one verb,
and that will carry over to other verbs.  It seems that player always gets
reset (see example below), so that behavior is a bit different.  Maybe I
missed it, but I didn't see this in the manual.

Are these implemented just as global variables?  Is their scope restricted to
the player, or are they really global, for everyone?

If I understand this correctly, this means that any verb that might suspend
should do something like my_var = dobj; so it's guaranteed not to change.  Is
this correct?

Sample code follows.

-- Amy

@program thing:test
player:tell("dobj: ", dobj);
player:tell("player: ", player);
.

@program thing:hack
dobj = "Hacked!";
player = #2;
this:test("args passed");
.

> hack thing
dobj: Hacked!
player: #75

(#75 is me)

---

From: Greg Hudson <[email-masked]>
Date: Tue, 30 Nov 1993 15:10:14 -0800

>From the MOO programmer's manual, under "Calling Built-in Functions
and Other Verbs":

	[...] the various built-in variables have the following
	initial values in the called verb:

	    [Initialization rules for this, verb, args, caller, and
	    player deleted]

	All other built-in variables (`argstr', `dobj', etc.) are
	initialized with the same values they have in the calling
	verb.

And under "Variables":

	   Variables are also "local" to a particular verb; every verb
	has its own set of them.  Thus, the variables set in one verb
	are not visible to the code of other verbs.

In particular, note the following test code's result:

	> @list me:test
	#950:"test"   this none this
	 1:  dobj = "foobar";
	> ;if (1) player:tell(dobj); player:test(); player:tell(dobj); endif
	#-1
	#-1
	=> 0

That is, you can only change your local copy of dobj, not your
caller's value, although verbs you call after changing your local copy
will get the value you set it to.

So no, you don't need to store the value of dobj if your task is going
to be suspended.

--GBH

---

From: [email-masked]
Date: Tue, 30 Nov 1993 15:19:06 -0800

Thanks.  That makes a lot more sense than what I was thinking was
going on!

-- Amy

---

From: Erik Ostrom <[email-masked]>
Date: Tue, 30 Nov 1993 16:43:05 -0800

>					    It seems that player always gets
> reset (see example below), so that behavior is a bit different.

It's worth knowing that any verb can set `player' within itself; and
wizardly code can set `player' and have the new value passed along to
verbs it calls, and so on.  So:

@program me:foo
player = #2;
this:tell(player);
this:bar();
.

@program me:bar
this:tell(player);
.

If the player who enters this ("me") is a wizard, e'll see "#2" twice;
if not, e'll see "#2" and then eir own object number.

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 30 Nov 1993 18:12:11 -0800

> Date:	Tue, 30 Nov 1993 12:27:25 -0800
> From:	[email-masked]
> 

Here is the relevant section from the manual:
-------------------------------------------------------------------------------
   Verbs can also call other verbs, usually using this syntax:

     EXPR-0:NAME(EXPR-1, EXPR-2, ..., EXPR-N)

EXPR-0 must return an object number; `E_TYPE' is returned otherwise.  If the
object with that number does not exist, `E_INVIND' is returned.  If this task
is too deeply nested in verbs calling verbs calling verbs, then `E_MAXREC' is
returned; the limit in LambdaMOO at this writing is 50 levels.  If neither the
object nor any of its ancestors defines a verb matching the given name,
`E_VERBNF' is returned.  Otherwise, if none of these nasty things happens, the
named verb on the given object is called; the various built-in variables have
the following initial values in the called verb:

    `this'
          an object, the value of EXPR-0

    `verb'
          a string, the NAME used in calling this verb

    `args'
          a list, the values of EXPR-1, EXPR-2, etc.

    `caller'
          an object, the value of `this' in the calling verb

    `player'
          an object, the same value as it had initially in the calling verb
          or, if the calling verb is running with wizard permissions, the same
          as the current value in the calling verb.

All other built-in variables (`argstr', `dobj', etc.) are initialized with the
same values they have in the calling verb.
-------------------------------------------------------------------------------
The description of the variable behavior is, I admit, a bit subtly presented,
but it's there.

> the player, or are they really global, for everyone?

They aren't global at all.  Rather, you should think of them as
implicitly-passed parameters to each verb.  Thus, it's as though each verb's
`dobjstr' parameter got the calling verb's `dobjstr' variable's value passed to
it.  So each verb has its own variable storage space and it can be assured that
it won't be changed by any other code in the MOO.  My verb's `dobjstr' is it's
own and your verb's is it's, but mine will be initialized to the value of yours
when you call me.

> should do something like my_var = dobj; so it's guaranteed not to change.  Is

No, see above.  No MOO variables ever change their values out from under the
verb that they're in.  They are *always* local variables.

	Pavel