MOO-cows Mailing List Archive
[SERVER] LambdaMOO 1.8.x feature wishlist
There have been lots of posts on features which some would like added to
the next (or some other future) version of the MOO, but I haven't really
read about any at the level of the internal virtual machine.
Some improvements I would like to see implemented:
Limit string and list lengths to prevent malicious programmers
(or unfortunate accidents) from bringing down any MOO currently in
Since I've not yet examined the VM at any length, it's harder for me
to accurately comment on these, but a few obvious ones (which,
since they're obvious, may already be done) are:
- differentiate between constant and mutable strings (String and
StringBuffer in Java)
- differentiate between property fetches and stores so that
property values could be cached if known to not be altered during
task execution. This would obviate the need for things like
ou = $object_utils; for each in ([1..max_object()])
- provide a mechanism for just-in-time compilation into native
object code. I wouldn't expect this to be fully implemented for
any given architecture, but it would allow motivated individuals
an opportunity to add support for it without each such person
rewriting it themselves.
(3) Customizable exceptions/error handling.
Okay, this is a server/db interface issue, but it comes into play
with the VM. Currently, the server says, "such and such error
results in such and such error value." For example, read() raises
E_INVARG when a "connection is closed while a task is waiting for
input but before any lines of input are received"). Now
that we can raise arbitrary values as exceptions, it is no longer
necessary to have somewhat arcane mappings from these errors to the
limited set of builtin error values. Instead, use property values
on $exception (or if you don't like creating a new server-assumed
object, maybe use $server_options.exception_*) to describe the
exceptions to be raised. E.g., $exception.divide_by_zero
To keep the overhead down, you could require these properties to
always exist in the database, and then those who don't want to
customize them could just leave them at their current default values.
Comments? Other ideas?
Subject Index |