MOO-cows Mailing List Archive
Re: [SERVER] LambdaMOO 1.8.x feature wishlist
On Mon, 11 Nov 1996, Erik Ostrom wrote:
> > Limit string and list lengths to prevent malicious programmers
> > (or unfortunate accidents) from bringing down any MOO currently in
> > existence.
> As others have pointed out, this doesn't finish the job, as I can still
> create an arbitrary number of properties. If you could limit the sizes of
> individual objects _and_ of individual variables, as well as the number
> of objects and forked tasks owned by a user, you'd be closer. (But the
> idea of the addition operator raising E_QUOTA still makes me squirm.)
Well, as I pointed out in a previous post, it would only happen when the
resource limit is exceeded, and that limit would presumably be set
pretty high for most MOOs. Memory limits are really analagous to
existing time limits. Your addition operator can already time out if
it runs out of tics; I think it should "space out" if it runs out of
> > - differentiate between constant and mutable strings (String and
> > StringBuffer in Java)
> So, this is the request for the _addition_ of a mutable string data
> type, right?
No no no no no. The example I gave was misleading; I'm sorry for the
confusion. What I meant on this suggestion (all items) were changes to
the VM to make it more efficient -- changes which (except for the time
and/or memory savings) should be invisible to MOO programmers.
The whole idea for this suggestion just came out of reading Meyer's More
Effective C++, Item 17, where he discusses implementing lazy evaluation
of strings, and lazy fetching of values from a database. Both examples
led me to think of possible optimizations to the MOO VM, namely
distinguishing between variable and property reads and writes.
I don't know enough about the MOO VM to know whether either of these
would be an improvement, but it seemed logical.
However, the example I gave was misleading. I really meant altering how
strings (lists, property values, ...) are handled internally, to more
efficiently handle those data types. I would definitely be opposed to
adding a new type to MOO (except for possibly binary like LPMOO has,
or maybe other containers than lists, such as hashtables).
> > (3) Customizable exceptions/error handling.
> What would you use this for? Would you use object numbers as your
> exceptions? That'd be sort of neat.
Well, as I also said in a previous post, I had really just thought of
using integers, because tossing objects seemed kind of pointless.
On second consideration, (static) objects might be kind a better way to do
the same thing I have in mind:
" stuff that throws $exceptions";
except e ($exception.server_exploded)
"Catch exceptions which require further action";
except e (ANY)
"Catch any other exceptions (including badly formatted ones,";
" i.e., ones which aren't objects) and print a user-friendly msg";
except e (E_INVIND)
player:tell($exception.unknown.name + ":" + tostr(e));
"Yeah, I know, it doesn't handle typeof(e)==LIST nicely";
"it's just an example";
Subject Index |