Subject: Another dream function...

From: [email-masked] (Rob Thomas 890-7033 Mathematical Sciences Dept., Univ. of Alabama-Huntsville)
Date: Wed, 12 May 1993 16:37:24 -0700

This is such a completely tangential item, I don't know how it 
even relates to the discussion of BREAK statements and the 
like, but I'd like to see a function that can be called from 
within a verb which allows an object to refuse being matched 
by the parser. For example, if I define a "get" verb on a 
room, used for something unrelated to picking up objects, and 
I still want to be able to pick things up in the room, I have 
to write my own matching and hope the "get" verbs on the 
objects to be picked up are +x. Difficulty of actual server-coding 
aside, it would be much easier to be able to stick a function 
call in the verb which pops the parser back up to the 
object-matching level, enabling -x verbs to be called in such 
a situation, and allowing programmers to more flexibly specify 
situations in which calls to a given verb are not allowed.
 
Another example:
 
$thing:get this none this rd
 
if(this.location == player)
  "here's our hypothetical function";
  refuse_match();
else
  this:moveto(player);
endif
 
The way "get" usually works (in the distributed core, that is) 
is that if I have an object in my inventory called "thingy," 
there's an object in the room also called "thingy," and I want 
to pick up the thingy in the room, I will be unable to match 
it because the parser will get an ambiguous match from the 
thingy in my inventory. Likewise, I won't be able to drop the 
thingy I have.   
 
In the above verb fragment, I assume the following change has been 
made: In the case of an ambiguous match encountered by the 
built-in parser, it takes each object in turn and executes the 
called verb until one of the verbs executes completely without 
refusing the match. Any verb called from the command line can 
refuse matching whether it has been matched ambiguously or 
not. Thus the "get" verb on the room mentioned previously 
would in fact be matched by the parser, but a refuse_match() 
stuck in that get verb would force the parser to keep looking.
 
The way I see it, the refuse_match() function should return 
E_PERM or something if(callers()) because there's no reason I 
can see to refuse matching except at the top level. The 
real conflict I can see is people who program verbs which go 
through code which actually does stuff on the object in 
question, then ends the verb with a refuse_match() rather than 
a return. That could be problematic, though I'm not sure 
exactly how just yet.
 
In the case of "get" one would be inclined to argue that you 
can still pick up the object by it's object number, but I'm 
thinking in terms of Joe Nonprogrammer, who, ideally, should 
be completely shielded from the underlying structure of the 
MOO. Of course, that doesn't ever work out in reality, but 
it's a goal, anyway.
 
Thinking too much on too little sleep,
==== Rob.

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 12 May 1993 17:09:13 -0700

> Date:	Wed, 12 May 1993 16:37:24 -0700
> From:	[email-masked] (Rob Thomas)
> 
> by the parser.

I think that making this a built-in function is a bit heavy-weight and leads to
a bunch of semantic difficulties, some of which you mentioned in your post.
If, instead, parsing is done in the DB, then the new (1.8.0) exception handling
mechanism would be sufficient; you simply raise a particular kind of error to
`throw' control back to the parser.

	Pavel