Re: verb protection

• Date: Thu, 3 Oct 1996 04:57:59 PDT
• From:
  Michael Moore <mike@mail.datasys.net>
• CC: moo-cows@parc.xerox.com
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=us-ascii
• References: <Pine.GSO.3.95L.961003010639.22042B-100000@unixs1.cis.pitt.edu>

James R O'Kane wrote:
> 
> I was thinking today during a boring calc recitation about ways to keep
> people from over-riding verbs that i didn't want them to. and i came up
> with 2 possiblilities..
> 
> both involve adding props similar to the $server_options.protect_foo where
> it's .protect_verbname.
> 
> the first way would involve editing $add_verb and/or $bf_add_verb to
> return E_PERM if .protect_verbname exists and is true and player !=
> wizard.

You also have to watch out for set_verb_info().  The matter is further
complicated by the fact that verbs can have multiple names, or can match
patterns.  Suppose you want to protect $player:notify()--How would you
keep someone from overriding it with a verb named :not*()?

> 
> the second way is to have set_verb_code add a pass(@args) to the verb at
> compile time, if it can't find it in the verb already..

What if I put a pass() in the verb code, in a place where it will never
execute?  What if the verb is supposed to return a result?  A simple pass()
is not appropriate in all circumstances.

> 
> i see pros and cons to both ways.
> pros to way 1: it gets the job done and seems to be the easiest.
> cons to way 1: it stops people from making _any_ additions down the line
> with out wizperms..even if they plan to use pass()

In previous discussions on this topic, it was stated that a non-overridable
verb should be overridable by a wiz or the owner of the verb being overridden-
In the same way that a non-readable property can be read by a wiz or the owner
of the property.

I find that logical and consistent with the way things are done permissions-wise
elsewhere in the server.

> 
> pros to way 2: it allows people more freedom to add verbs as they choose
> and pass(@args) is always called.
> cons to way 2: it'll be a bit tick heavy to search for any pass()'s in the
> verb and it kinda produces random results if programmers forget that
> pass() is added.

It may be tick-intensive, but set_verb_code() isn't called frequently.  If you
did it this way, then you'd want the pass() to be the first line after the
documentation lines anyway--it's the only way to be sure it will execute every
time.

• verb protection
• From: "James R O'Kane" <jrost10+@pitt.edu>

• Prev: Re: verb protection
• Next: Re: verb protection
• Index: MOO-cows
• Thread: MOO-cows