Re: Non-overrideable verbs

• Date: Mon, 29 Jul 1996 21:51:17 PDT
• From:
  RICHARD JACOB CONNAMACHER <phantom@sfsu.edu>
• cc: moo-cows@parc.xerox.com
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <16997073@prancer.Dartmouth.EDU>

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

• Re: Non-overrideable verbs
• From: Andrew Ayre <A.J.Ayre@e-eng.hull.ac.uk>

• Non-overrideable verbs
• From: Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)

• Prev: Re: Non-overrideable verbs
• Next: Re: Non-overrideable verbs
• Index: MOO-cows
• Thread: MOO-cows