MOO-cows Mailing List Archive
RE: Production release 1.8.0 of the LambdaMOO server
--- Christopher Unkel wrote:
>Under your proposal, if you want a built-in to be wizard-restricted (or
>have one currently that is this way), you have to write #0:bf_FOO:
>Given that this is the most likely case of wanting to modify the behavior
>of a built-in, it seems silly to force this code to be written over and over.
Actually, the code could look like this and only exist once:
protected = $server_options.("protect_"+verb[3..$]);
protected = 0;
if (!protected || caller_perms().wizard)
My personal idea on the matter is this:
FOO() is called by a $luser/$wizard
If $server_options.protect_FOO exists and is true, and !callers_perms().wizard,
Provided we haven't bounced the $luser out on an error,
if #0:bf_FOO() exists, call it instead of the built-in, unless the calling
verb is #0:bf_FOO().
otherwise, go ahead and call FOO().
This seems pretty straightforward, and provides a wizard with the ability
either to protect all built-ins with the $server_options method or to filter
them manually. It also gives a wizard the ability to replace built-ins with
another action, yet still allows the built ins to be called under special
circumstances or as part of the #0.bf_FOO() itself.
A tiny amount of backwards compatibility is lost, but the new server has only
been out for what. . . 3 days? The grief would be minimal. As well, it would
be very easy to change code written for 1.8.0p1 to this system.
If backwards compatibility is REALLY desired, a notion of
$server_options.armour_plate_FOO could be developed and it would work this way.
To recreate your supporting example:
>Supporting example: $server_options.protect_create is set true because
>programmers are calling raw create() instead of requesting an object from
>the recycler, resulting in skyrocketing max_object() and gobs of recycled
>objects just sitting around. #0:bf_foo is written to call the recycler's
>create; problem solved.
>However, there needs to be some way to call the built-in create, because:
>(1) Sometimes a fresh object is really desired, for example when creating
>new players, and
>(2) The recycler's create is going to need to call it if there are no
>recycled objects available.
Under my system, this would work as follows:
(1) Leave $server_options.protect_create at 0.
(2) Write the #0:bf_create() as follows:
if (caller == $recycler && callers() == "do_hard_create")
Problem solved. Now if a wizard REALLY wants to do a create(), s/he calls
This is as it should be as the $recycler has taken over the job of managing
object creation, recycling.
For other problems, a more complicated perms check could be done.
I am currently working on a couple of patches to the server that will render
many of the built-ins meaningless. It would be nice if I could redefine some
built-ins for everyone (including .wizards) with out resorting to more server
FYI, the patches I am working on are "verbing properties" and multiple
inheritance. When I have shaken the problems out of the drafts, I will post
them. When I have finished the patches, I will make them
Subject Index |