[MUD-Dev] about MOO

[Andru Luvisi]

On Fri, 19 Nov 1999, Ilya, Game Commandos wrote:
> Okay, just a brief inquiry for those of you knowledgeable in this area,
> which I suspect are more than just a few.  Why not MOO?  Meaning,
> it seems a reasonable set of code to start with, even for coding some-
> thing a bit more goal-oriented than it seems it's usually used for.
>
> Are there obvious (or less obvious) restrictions or catches or
> gotchas which should direct one away from serious exploration?
> 
> Many thanks to Ian M. who has already given me a very brief
> intro.

My experiences with MOO were in designing a multi-national money and
banking simulation (MoneyMOO, now known as MudBank and written in LPC. R&D
has since ended, but what was built is available at
http://www.sonoma.edu/projects/mondy/)  and in setting up virtual
classrooms for professors.  I have never tried to use a MOO as a game
server, so my particular complaints might not be relevant to your
applications.

MOO isn't terribly accommodating to the notion of disposible objects.  In
our case, we needed to create hundreds or thousands of agents, but we
didn't want them hanging around once the simulation ended.  We ended up
keeping a cache of unused objects of each type.

Transparent persistance isn't always a good thing.  It can cause the
effects of a bug to remain even *after* you have fixed the bug.

Moo doesn't have any builtin mapping/associative array/hash table type.

All verbs (aka functions) run with the permissions of their owner unless
the owner is a wizard and the function changes it's permissions.  This is
like having *all* programs you ever write be setuid.  I much prefer the
recently developed stack based security model used by many LP muds, where
by default you can only do something if *every* object on the call stack
has the permissions to do it.  You have to do extra work to be insecure.
On MOO, you have to do extra work to be secure.  A classic mistake is to
have function A call function B, where function A drops privs, but
function B doesn't check who called it, so if an unpriveleged programmer
calls function B directly, function B runs with wiz privs.

MOO doesn't have a preprocessor.  Opinions are varied on whether this is a
good thing or a bad thing.  Personally, I like having a preprocessor.

MOO reformats your code for you.  I *hate* this.

MOO throws away comments.  If you want to put in persistant comments, you
have to put them in as expressions which consist of only a single string.
This isn't a problem really, but I think it's dumb.

Andru
--
-------------------------------------------------------------------------- 
| Andru Luvisi                 | http://libweb.sonoma.edu/		 |
| Programmer/Analyst           |   Library Resources Online              | 
| Ruben Salazar Library        |-----------------------------------------| 
| Sonoma State University      | http://www.belleprovence.com/		 |
| luvisi at andru.sonoma.edu      |   Textile imports from Provence, France |
--------------------------------------------------------------------------




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev