# call_function() and $bf_FOO()

ThwartedEfforts (abakun@forney.scinc.com)
Sun, 28 Apr 1996 11:08:49 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).

    This funcationality was removed.  See the ChangeLog.

    from 1.8.0:
    -- Backed out the change in 1.8.0beta3 where the parser was replacing calls of
       the form `call_function("foo", ...)'  with simply `foo(...)' if `foo' was a
       known function.  While this change made sense for porting whole databases
       between server versions, it made it harder to port single verbs or objects
       from place to place.  (Thanks to Richard Connamacher for being persistent
       enough to finally make me see this point.)

    >   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
    > 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.

    I actually wrote a patch that allowed you to do this (in a slightly different
    manner; you were able to make a new builtin that did nothing, and then
    override that).  I was talked out of actually doing/using this for a number
    of reasons, the main one being that the builtin functions would not be
    consistant.  You should be able to rely on what the server provides from
    MOO to MOO, and only have to worry about the local changes in the
    database.  New undocumented builtin functions create too much uncertainity
    in the server<->database interface.  This is nearly analogous to:

    @program #0:bf_open_network_connection
    return listappend(@args);

    or

    @program #0:bf_create
    return recycle(@args);

    Really, if one wants to add builtin functions, one should take the time
    to learn the server internals and C.  Plus, you'll get better performance
    that way.
    And in an ideal universe, you'd have no directly callable builtin
    functions, but have to go through a util-type/frob-type object for
    abstraction purposes.
    Of course, it's nice to have a shorthand for verbcalls, perhaps having
    a default object they are called on (an implicit `this'?).  Of course
    this is what $verb() is for, and you can tell by sight that the
    programmer knows they are calling a verb (unlike making something
    wiz-only via $server_options and overriding it).

    > maybe just make recycle() refuse to recycle it?  I don't see how the MOO
    > could function at all without #0, nor do I see any reason why it should
    > ever need to be recycled.  Of course recycling $player could probably do

    There is nothing special about #0 besides how the code (un)parser interpretes
    $verb() and $prop.  Now that you can dynamicly change which object gets login
    requests, the significance of #0 is even less important.  Overload recycle()
    if you don't want it to be recycled.

    Andy.