Subject: dump/reload messes verb named 0* 1* 2* 3*

From: Larry Masinter <[email-masked]>
Date: Sun, 11 Jul 1993 16:43:02 -0700

Hi --

I added a feature to the gopher slate, to allow a shorthand '10 on
slate' to mean 'pick 10 on slate'. I was gone for a week -- when I
came back, I found out that the object wasn't working.

It seems that verbs after one named 1* 2* 3* 4* 5* etc. don't get restored
properly. I tested this with a small database:

Before checkpoint & restart:
================================================================
>; verbs(#75)
=> {"verb1", "verb2 1* 2* 3* 4* 5* 6* 7* 8* 9*", "verb3"}
>@list #75:verb1
#75:"verb1"   none none none
 1:  return "This is verb1";
>@list #75:verb2
#75:"verb2 1* 2* 3* 4* 5* 6* 7* 8* 9*"   none none none
 1:  return "this is verb2";
>@list #75:verb3
#75:"verb3"   none none none
 1:  return "this is verb3";

================================================================
after checkpoint & restart:
================================================================
>; verbs(#75)
=> {"verb1", "verb2 1* 2* 3* 4* 5* 6* 7* 8* 9*", "verb3"}
>@list #75:verb1
#75:"verb1"   none none none
 1:  return "This is verb1";
>@list #75:verb2
#75:"verb2 1* 2* 3* 4* 5* 6* 7* 8* 9*"   none none none
 1:  return "this is verb3";
>@list #75:verb3
That verb has not been programmed.

---

From: Roger Crew <[email-masked]>
Date: Sun, 11 Jul 1993 18:56:36 -0700

The problem is that giving a numeric name to a verb thoroughly confuse
the verbname matcher.

Currently, a name string that also happens to be a decimal number n is
taken to refer to the (n+1)th verb in the object's verblist.  Note
that there needs to be *some* method of referring to a verb
independently of its given (command-name) name; without this you would
lose completely if, say, you named a verb "*" and it wasn't the last
verb on an object's verb list --- there would be NO WAY to refer to
any of the following verbs.

What seems to be happening is that in the case of numeric names, it
STILL checks for string matches on earlier verbs.  Thus, in your
example, when restoring the db, the code for verb #75:2 (named
"verb3") is read and we find that the second verb on #75 (i.e., #75:1,
named "verb2 1* 2* 3* ...") has a name matching "2".  This causes the 
previous code for #75:"verb2" (#75:1) to get overwritten.
This is indeed broken.

The quick fix is to change db_read to interpret the verb number directly
and not call match_verbdef.  However, to fix the more fundamental problem
here I'll also suggest

1.  changing delete_verb,verb_info, verb_args, verb_code, set_verb_info, 
    set_verb_args, and set_verb_code, to allow a NUMERIC argument in the 
    verbname slot, e.g., set_verb_info(#75,2,{#122,"rxd","verb3"}).
    STRING arguments would continue to work as before.

There are roughly 5-10 lambdacore verbs that need to use
numeric-string verb names (e.g., @program, @rmverb, @chmod ...);
once these are changed to use numeric names, one can then

2.  change match_verbdef(), used by the delete_verb,etc...
    in the case where the verbname argument is a STRING, to treat
    number strings no differently from any other name.  
    (i.e., put #ifdefs around that strtol call...).  This should probably 
    be done as a compile-time switch so that old dbs can continue to work...

This way delete_verb(#75,2) would delete the 3rd verb (remember we start with 0)
from #75, whereas delete_verb(#75,"2") would delete from #75 the verb whose name 
matches "2".

This would then allow numeric command names to work.

---

From: Pavel Curtis <[email-masked]>
Date: Mon, 12 Jul 1993 09:44:21 -0700

> Date:	Sun, 11 Jul 1993 16:43:02 -0700
> From:	Larry Masinter <[email-masked]>
> 
> properly.

This is a consequence of some very early design mistakes in MOO, having to do
with the use of numbers as indices into an object's list of verbs.  I will try
hard to put together a workaround for this buggy outcome in 1.8.0.

	Pavel