# Non-overrideable verbs

RICHARD JACOB CONNAMACHER (phantom@sfsu.edu)
Mon, 29 Jul 1996 21:51:17 PDT

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

    I can see a couple problems with this plan:

    1) A database transition would, in fact, be neccessary, because verbs
    are, in LambdaCORE< defined "rw" by default, so new verbs would be
    defined as non-overridable by default, which is IMHO a bad thing.  I
    would use 'p' (protected) or 'n' (non-overidable) as the perm for a
    non-overridable verb, and it has to be on for the verb to be overridable.

    2) verb names should be what's protected.  Treating a 'foobar any none
    none' differently from a 'foobar this none this' would cause more
    problems than it'd solve.  For example, because most +p protection would
    be used for +x verbs, you'd also have to include both set_verb_args() and
    set_verb_info() as potential screwing-things-up verbs and include an
    error to raise from them if that's not allowed.  It'd get messy.

    Also, I think the 'p' flag should be treated the same as the 'r' and 'w'
    flags:  people can override their own +p verbs, and wizards can override
    all +p verbs.  (Nonetheless, @verb and @rename shyould raise warnings and
    double check for permission before doing it, but that's a database thing)

    I think that non-overridable verbs would be a Very Good Thing, as long as
    it's done with simplicity in mind. :-)

    Phantom