MOO-cows Mailing List Archive
Date: Thu, 14 Sep 1995 16:48:52 PDT
From: email@example.com (Matt Pauker)
Content-Type: text/plain; charset="us-ascii"
I talked to Rob about this on MirrorMOO a few days ago, but I thought I'd
voice my opinion here as well...
Although I agree that redirecting non-existant builtin calls to a verb on
#0 would be nice, I don't believe it's a solution that is consistent with
how builtins are implemented in LambdaMOO. Calling a non-existant builtin
is about the worst mistake you can make in MOO - It's picked up when you
compile, not at runtime. Therefore, re-directing a builtin to a verb on #0
at runtime would not be consistant with this line of thinking.
Another reason for not redirecting verbs to #0 are the problems that could
arise from people calling a non-existant builtin, getting redirected to a
verb on #0, which has undesirable results for the programmer. That is, if
I port some code that calls a builtin called server_status() that's
supposed to return something specific, but the MOO I port it to doesn't
have a server_status() builtin, but a #0:server_status() verb, that verb
may not return what I want. Hopefully that made sense :)
So my suggestion is this: At bootstrap time, look for non-existant builtins
and notify the person bootstrapping (And write to the log) if one is found
(Giving them info such as object #, verb name, line, etc.). That way, if
the verb is something important, they can choose to adjust the verb before
starting the MOO. If they decide that they can fix it later, then have the
builtin call return an error (E_BFNF or whatever you wish to call it).
(Oh, BTW, someone mentioned that they wanted an ascii() function, but
didn't know enough LPC to write it...Here it is:)
string ascii(int num)
str = "x";
str = num;
That should (Assuming I didn't make a mistake...) give you what you want -
But remember, if you're using LPMOO 1.2, and you call ascii() with a number
< 32 (Which will return binary data), LPMOO will give you a buffer...
Subject Index |