Re: call_function() and $bf_FOO()

• Date: Sun, 28 Apr 1996 11:08:49 PDT
• From:
  ThwartedEfforts <abakun@forney.scinc.com>
• Cc: moo-cows@parc.xerox.com
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <Pine.LNX.3.91.960427185739.4759A-100000@darkowl.pr.mcs.net> from "Don Schwarz" at Apr 27, 96 05:43:48 pm

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

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

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