MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

RE: Bug? with builtin redirection

I agree this has some useful aspects, but I would advise against making the
server understand a different set of arguments.  For one, even though bf_move
can be written to completely change the nature of the way move() works, adding
more options to move() makes it operate differently than documented.  In 
practice, a typical application which makes use of bf_move (bf_anything really)
will only do so to further define limits and requirements to the nature of the way
move() operates without actually changing the core of how it works.  if you
make move() support more arguments, then any code you write that uses
that third argument becomes vastly different than documented, and that much
harder for other people to figure out, and also port to other MOO's.  the less than
true techy types are going to look at your code and get very puzzled as to what
that third argument in move() is all about.  (Here we have a builtin that doesn't
work the way it's described in the manual.  go figure. :)

So, since any code you write that wants to use move with a 3rd parameter would
be new code anyway, it's just as easy to call $lib:move (or whatever), which 
allows for a 3rd argument, instead of the builtin, which by definition does not.


----------
From:  Christopher Unkel[SMTP:cunkel@us.itd.umich.edu]
Sent:  Friday, March 22, 1996 2:19 AM
To:  Brian Buchanan
Cc:  moo-cows.PARC@xerox.com
Subject:  Re: Bug? with builtin redirection

On Thu, 21 Mar 1996, Brian Buchanan wrote:

> 
> Forgot to cc my response to Christopher Unkel, so reposting it here so I
> don't get asked again:
> 
> Yes, this was under 1.8.0p2, and yes $server_options.protect_move existed
> and was set true.

I awakened just enough to reproduce it.  I agree--this is not how it 
should work.  For the benefit of those no more awake than I was:

(1.8.0p2, with force_callers() patch):

$server_options.protect_move = 1
#0:bf_move tnt rxd
 1:  player:tell("Now in bf_move.");
 2:  set_task_perms(caller_perms());
 3:  return args < 2 ? E_ARGS | move(@args[1..2]);

A real verb would presumably do something differently if args was three, 
but here we just want to find out what's going on.  As long as it's 
called with at least two arguments, it should work fine and disregard extras.

;move(#2, #61, "blah")

#-1:Input to EVAL, line 1:  Incorrect number of arguments
... called from built-in function eval()
... called from #57:eval_cmd_string (this == #2), line 18
... called from #57:eval*-d (this == #2), line 10
(End of traceback)

(notice #0:bf_foo is not involved).

Since one of the most desirable (and backwards compatible) ways to modify 
a built-in function is to add an extra optional argument that changes its 
behavior, this probably isn't how this should work.

  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/
Home | Subject Index | Thread Index