[Prev][Next][Index][Thread]

# Re: [SERVER] LambdaMOO 1.8.x feature wishlist

- Date: Mon, 11 Nov 1996 18:16:34 PST
- From:
- cc: moo-cows@parc.xerox.com
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <199611120056.TAA13528@mole.research.att.com>

    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:

- Re: [SERVER] LambdaMOO 1.8.x feature wishlist

- From: Ahn Jin-su <jsahn@ee.snu.ac.kr>

References:

- Re: [SERVER] LambdaMOO 1.8.x feature wishlist

- From: Erik Ostrom <eostrom@research.att.com>

- Prev: Re: [SERVER] LambdaMOO 1.8.x feature wishlist
- Next: Re: [SERVER] LambdaMOO 1.8.x feature wishlist
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index