Re: call_function() and bf_FOO()

• Date: Sun, 28 Apr 1996 07:11:14 PDT
• From:
  Richard Godard <rgodard@divsun.unige.ch>
• Content-Type: text/plain; charset="us-ascii"
• In-Reply-To: <Pine.LNX.3.91.960427185739.4759A-100000@darkowl.pr.mcs.net>

>  1) The server should change any calls to call_function(foo, ...), where
>foo is a literal string and represents a valid built-in function, back into
>a standard built-in call (yes again, but #2 will fix the reason Pavel
>decided not to implement this before).

Well that could defeat the readability of some code where call_function()
is called on purpose, of course it's a matter of taste, I guess some good
comments could do the job :-)

>  2) When programming verbs (with set_verb_code or .program), any built-in
>calls where the function is not known should be changed into call_function()
>calls, similar to what it does when loading the DB, except that instead of
>sending the warning to the log, it should somehow notify the programmer
>(maybe by notify()ing the player, even though that's probably a bad idea).

So all typoes would be changed to call_function calls ?
I personnally prefer the compiler to tell me I try to compile a verb with a
bf that doesn't exist... that way I know I have to call call_function() and
to write some alternate code if that fail.
But again we could argue endlessly on that one... depends of the
programming style :-)

>  3) call_function() should be changed so that if the first argument isn't
>a known built-in function, it checks to see if a callable verb is defined on
>#0 with the name bf_<name of function>, which will be called in the same way

Heh write a wrapper for call_function() :-)

$bf_call_function tnt rxd
set_task_perms(caller_perms());
try
  return call_function(@args);
except (E_INVARG)
  "Check if the E_INVARG was raised by call_function and eventually (if the
verb exist, if the bf is protected, ...) call
this:("bf_"+args[1])(@args[2..$]) or raise(E_INVARG)";
endtry

>that it would be if the function existed and was protected.  This will allow
>people to do something like:
>    #0:bf_listassoc this none this rxd
>      try
>        return call_function("listassoc", @args);
>      except e (E_INVARG)
>        return $list_utils:assoc(@args);
>      endtry
>and have the listassoc() built-in work whether the patch was installed or
>not.

IMO everyone is used to call $list_utils:assoc (that is in a standard
lcore), to make the code more compatible people should keep calling
$list_utils:assoc and it is the code of $list_utils:assoc that should be
changed to something like:

$list_utils:assoc
try
   return call_function("listassoc", @args);
except (E_INVARG)
   "eventually execute the old code if the E_INVARG was raised by
call_function (which means the bf doesn't exist)";
   "if the E_INVARG was raised by listassoc, then raise it, that means the
arguments for the listassoc are not ok.";
endtry

That way the speedup will be applied to all the existing code that call
$list_utils:assoc.

Just my $0.02


Richard




---
"640K ought to be enough for anybody."
    -- Bill Gates, 1981

• call_function() and $bf_FOO()
• From: Don Schwarz <darkowl@darkowl.pr.mcs.net>

• Prev: Re: call_function() and bf_FOO()
• Next: call_function() and callers()
• Index: MOO-cows
• Thread: MOO-cows