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. :-)


Follow-Ups: References:

Home | Subject Index | Thread Index