MOO-cows Mailing List Archive
Re: Non-overrideable verbs
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. :-)
Subject Index |