MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

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 
memory.

> >    - 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:

        try
          " stuff that throws $exceptions";
        except e ($exception.server_exploded)
          "Catch exceptions which require further action";
          player:tell("Run away!");
        except e (ANY)
          "Catch any other exceptions (including badly formatted ones,";
          " i.e., ones which aren't objects) and print a user-friendly msg";
          try
            player:tell(e.name);
          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";
          endtry
        endtry
Follow-Ups: References:
Home | Subject Index | Thread Index