MOO-cows Mailing List Archive
RE: Production release 1.8.0 of the LambdaMOO server
Date: Tue, 12 Mar 1996 11:30:45 PST
From: "Seth I. Rich" <firstname.lastname@example.org>
Content-Type: text/plain; charset="us-ascii"
>> If you must do something like this I would MUCH prefer the following:
>> -- If a built-in function FOO has been made wiz-only (by defining
>> $server_options.protect_FOO with a true value), and a call is made
>> to that
>> function from ANY VERB NOT DEFINED ON #0,
>> === ----------------------
>> the server first checks to see if the verb #0:bf_FOO exists.
>> If so, it calls it (REGARDLESS OF THE PERMISSIONS OF THE CALLING
>> If not, E_PERM is raised if the calling verb is nonwizardly
>> (i.e., same behavior as before if #0:bf_FOO doesn't exist).
>Problem with this: $server_options.protect_FOO doesn't mean what it's
>supposed to any more. .protect_FOO is supposed to mean that foo() is
>wiz-restricted. Now it means that *nobody* can call foo(), except from
>#0. This seems to me to be a much more serious illogicality than the
>current system (not to mention backwards-compatibility).
Although it makes sense, from several perspectives:
- When a programmer calls foo(@args), it's 100% consistent what happens. If
$server_options.protect_foo exists and is true, then either #0:foo(@args)
is caller or E_PERM is raised/returned, otherwise foo(@args) is called by
the server. (These rules are suspended for builtins called from #0.)
- The behavior of a builtin should be consistent regardless of who calls it.
(Yes, queued_tasks() is the exception to this, but I'd also love to see
For my personal uses, this change would make much more sense. I've written
wrappers for almost all db-modifying builtins, and I'd -love- to be able to
just have the server deal with forcing the #0 wrappers to be called. However,
this change is almost useless to me if wizardly calls stomp forward and
ignore the wrappers.
>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.
Why do you think this is the most likely case? Why would one write a wrapper
which didn't do anything?
>> The problem with the previous version is if I'm looking at some random
>> verb in the db and I see a call `create(...)', given that #0:bf_create
>> could do completely arbitrary things, I have NO IDEA what this call is
>> going to do unless I know the wizardliness of the verb.
>You have no idea what any code is going to do unless you know what
>permissions it's going to run under, including whether they are wiz perms
>(or programmer perms, and the individual player.) You never have and you
This is an incorrect claim. If I look at verb code, I can tell what it's
going to do, or at least boil it down to a set of possibilities (it may
bomb here, it may bomb there, and so forth). If we introduce the possibility
that under some circumstances it may call verbs on #0 instead of the
builtins themselves, and this is determined based on the player's .wizard
bit as opposed to explicitly by code, we can't predict behavior anymore.
Take another example -- some time ago people wanted to "regularize" the x bit,
so that a programmer could call any verb she controlled as if its x bit were
set. I objected to this for the same reason -- the language should have the
same result, if given the same command.
>The permissions of a verb determine what everything will do:
>what verb calls do, whether property assignments work, what built-ins will
>allow you to do, etc.
But those permissions don't cause the server to make assumptions which
will result in different code being called, silently.
Seth / Blackbriar
Seth I. Rich - email@example.com
There is nothing more precious than
Rabbits on walls, no problem. a tear of true repentance.
Subject Index |