Non-overrideable verbs

• Date: Sun, 28 Jul 1996 11:29:30 PDT
• From:
  Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)
• Reply-To:
  manta@dartmouth.edu

Here's a server modification I have been working on.  Any comments?
One change that I've been considering is a modification to add verb arguments
into criterion for overriding:
this way, "l*ook this none none" would not override "l*ook any in this", for
example.

Thanks to Richard Godard for sending the message to moo-cows suggesting this.

**********************************
* Draft:  -o_Verbs               *
******************************************************************************
* Date:                      07/27/96   Patches needed:                 None *
* Written by:                   manta   ICBINL?                 More-or-less *
******************************************************************************

*	Each verb is given a new possible flag 'o' for "overrideable"

*	This flag is set using add_verb(), or set_verb_info().  Only wizards
and
	owners of the verb can change the setting or a -w verb.

*	This flag can be viewed using verb_info().

*	If verb B is on an object that is a descendant of an object containing
verb
	A and it is possible to call verb B using by name that would have
referred
	to verb A if verb B did not exist, verb A is considered to be
'overridden'.

*	A 'conflict' is created when verb A exists in the database that
overrides a
	verb B, where verb A is -o, and verb B is neither wizardly nor owned by
the
	owner of verb A.

*	A conflict can be created in one of three ways:
	*	An overrideable verb is set to -o
	*	A verb is renamed
	*	An object is chparented

*	To prevent the creation of conflicts, these functions must be checked:
	*	set_verb_info()
	*	chparent()
	*	add_verb()

*	set_verb_info() can cause four types of conflict:
	*	In a call to rename a verb, the new name conflicts with a -o
verb on an
		ancestor.  A call that would cause this conflict would return
E_PERM.
	*	In a call to change the owner of a verb that overrides a verb
on an
		ancestor to a non-wizard or an owner other than the owner of
the
		overridden verb.  A call that would cause this conflict would
return
		E_PERM.
	*	In a call to change the flags of a +o verb to make it -o, a
conflict is
		created by a verb on a descendant.  A call that would cause
this conflict
		would return E_INVARG.
	*	In a call to rename a -o verb, the new name conflicts with a
verb on a
		descendant. A call that would cause this conflict would return
E_INVARG.

*	add_verb() can cause two types of conflicts:
	*	The new verb conflicts with a -o verb on an ancestor.  A call
that would
		cause this conflict would return E_PERM.
	*  The new verb is -o and conflicts with a verb on a descendant.  A
call
		that would cause this conflict would return E_INVARG.

*	chparent() can cause one type of conflict:
	*	A verb on the object or one of its descendants conflicts with a
-o verb
		on the new parent or one of its ancestors.  A call that would
cause this
		conflict would return E_PERM.

*	In the server, the flag will be E_NOT_O, and a 1 will indicate a -o
verb
	and a 0 will indicate a +o verb.  This will mean that no database
	translation will be necessary when the patch is applied.  Under the
current
	server code, a database featuring +o and -o verbs is compatible with a
	database without them with no translation. 

**	A minor incompatibility will be created, however.  This incompatibility
	will only manifest itself in verbs that use property_info() or
	set_property_info(). Since a new flag has been added, it is possible
that
	this will break some verbs that directly compare the output of
	property_info() with a string instead of using index().  This should
not be
	a problem for most databases as this is generally considered to be bad
	coding.

• Re: Non-overrideable verbs
• From: Richard Godard <janus@cam.org>
• Re: Non-overrideable verbs
• From: RICHARD JACOB CONNAMACHER <phantom@sfsu.edu>

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