Subject: Re: @foo me is <value>

From: [email-masked]
Date: Mon, 4 Jan 1993 05:26:00 -0800

Amy / jaime writes:

> The message syntax is really handy.  
> (You can just create a property named foo_msg, and then the server
> automatically interprets "@foo <object> is <message>" to let you set the
> foo_msg of anything you own.  Permissions are handled automatically.)

Almost. If you have a property whose name ends in _msg, it's lucky enough
to be treated specially by various LambdaCore commands (@messages, for 
example).  If I give a command of the form 
  @<anything> <object> is <something>
and it doesn't match in any of the usual ways: player, location, dobj, iobj,
and (in the present LambdaCore) player's my_huh (features), location's
here_huh (exit names), it goes back to $last_huh:@* which will look for an
appropriately named property and assign the value if permissions allow.

> Here's my question:
> Why not generalize this, and drop the need for adding "_msg" to the 
> property name?  (The slot would now be named "foo" instead of "foo_msg", 
> and all slots could be set in this fashion.)  This would be done last, 
> so any existing @foo verbs would take priority, if they exist.  The server 
> would need to check the type of the <value> and produce an appropriate 
> error message.

I actually like this idea -- it has potential to eliminate the need for
the @set command (although @set should stay around for those who can't
set property values with eval).  Why not make $last_huh:@* check first
for the existance of a _msg property with the appropriate name and, if
that's not found, then check for the existance of a property with the name
as originally given?

This would not be too hard to implement, as I see it (I think I might just
go ahead and do it on OpalMOO, since we're ripping LambdaCore to shreds
anyway).

Seth / Blackbriar