# call_function() and bf_FOO()

Richard Godard (rgodard@divsun.unige.ch)
Sun, 28 Apr 1996 07:11:14 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >  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