# Non-overrideable verbs

Jefferson M. Dubrule (Jefferson.M.Dubrule@dartmouth.edu)
Sun, 28 Jul 1996 11:29:30 PDT

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

    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.