MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: Scattering assignment
-
Date: Mon, 18 Nov 1996 12:06:34 PST
-
From: Eric Mercer <mercere@netcom.ca>
-
Content-Type: text/plain; charset="us-ascii"
At 08:23 AM 11/18/96 PST, Chris Schlesiger wrote:
>I've gotten to really like the scattering assignment in the new server
>version. I was wondering what people would think of adding on to it the
>following: Type requirements.
I agree this would be nice, primarily to prevent threads from failing
outside the verb where the real bug is. That's more of a problem in the -d
verb world, which of course we're all moving away from with the great new
error handling routines, but there's a lot of LambdaCore legacy code around.
I wrote a small util to do this checking, but including a call to it in
every executable verb I own seems like it isn't worth the processing time
(unless your code is routinely buggy). I'm thinkng if the checking was done
by the server it might be much faster, but again, maybe not worth the
processor time. The in-db approach does let you also test the values of
LIST elements, though, which the proposed type-checking system wouldn't.
I'd like to see an automated type checking system eventually available (CASE
tool) that could look over your code and that of verbs called and report
that there is inconsistant typing, but MOO's weak typing and -d verbs
probably make that a distant dream. You'll note the top line in my sample
code uses a common DU MOO documentation header, which is intended to help
make that CASE tool work eventually, and for now makes it easier on
programmers, at least. The type can also have the form {LIST, INT} to
indicate either a LIST or INT is acceptable for that arg.
In any case, here's my type-checking util...
"invalid_args(values LIST, template LIST [, template2 LIST ...]) -> result
BOOL";
"Checks the args sent to a verb for conformity to a data types";
"template, or to any of a set of templates. Returns true if none of";
"the templates fit.";
"A typical template might be {INT, LIST, {FLOAT,STR}} in which";
"args[1] is an INT, args[2] a LIST, and args[3] a FLOAT or a STR.";
"Note that the calling verb might subsequently test args[2] against a";
"new template to insure that LIST itself has correct data types.";
"ex: invalid_args(args, {INT, LIST, {FLOAT,STR}});";
{values, @templates} = args;
for template in (templates)
for arg in [1..length(values)]
if (typeof(template[arg]) == LIST)
if (!(typeof(values[arg]) in template[arg]))
continue template;
endif
elseif (typeof(values[arg]) != template[arg])
continue template;
endif
endfor
return 0;
endfor
"No template matched";
return 1;
Eric Mercer (EricM @ Diversity University and BioMOO)
Home |
Subject Index |
Thread Index