# verb protection

Michael Moore (mike@mail.datasys.net)
Thu, 3 Oct 1996 04:57:59 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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.