[MUD-Dev] Introduction

[Chris Gray]

[Miro:]
:This is an expensive tradeoff, and one you want to think CAREFULLY about.
:You can go for strongly-typed (i.e. all /variables/ are declared in advance,
:and dynamically-typed (i.e. data keeps type-tags, and types are checked
:in runtime). If you do strongly-typed language, you'll be able to compile
:it to C without too much pain, and gain a lot of speed. Unfortunately, the
:payoff is in the ease of programming. MUD tend to use mixed datastructures
:a lot, and when you're able to just say 'this is a list' without worrying
:about the types of the elements inside it (as dynamically-typed languages
:allow), you can spew working code at blinding speed, and you'll also make
:your hired coders much happier.

Actually, I've gone somewhat futher than that. The DB is strongly typed,
too. Any reference to a property on a DB entity is done in such a way
that the type of the property is known, so the type of the retrieved
value is known. I support lists of stuff (all the same type, as you say),
and have never noticed any difficulties. Can you give me an example of
where you would want to have a list of different types of things, and
how you want to go about processing the list?

Personally, I'd much rather work with code that wasn't "spewed at blinding
speed" - it is much more likely to work properly, and to handle the
inevitable exceptional cases. I think what it comes down to is the
experience of the individual. Until you've tried a system that is
strongly typed, but nevertheless has the flexibility of a MUD system,
I doubt a proper comparison can be made. I've worked with several weakly
typed systems, and am forever frustrated by their inability to detect
even the most obvious of my blunders.

Now, I'm on the exact opposite side of the boat in the area of objects
and properties. I don't have any fixed object formats - they are all
just a collection of properties, either inherited (*without* copying),
or specified explicitly. (Well, there is a small base structure for an
object, which I call "things" since they are used for rooms, etc. as
well.) Doing this *does* cost me performance - every property reference
is a scan of a small array (plus possibly following inheritance pointers),
but the flexibility is tremendous. I can add a property to the system at
run-time, and attach it to whatever objects I chose. It will be ignored
by old code, but it works just fine with the new code it was created for,
is inherited like anything else, has an appropriate default based on it
type, etc. This also saves me huge amounts of DB space compared to some
systems I've seen or heard about. A property needs to be present on a
thing only if it is different from the default, and different from what
is inherited.

:> force people to pre-declare variables, so that you can access them via
:> something other than their name at run-time (e.g. an offset from a
:> current scope pointer, allocated on entry to the scope).
:
:Uhhh, why do you need that? It looks like terribly unsafe programming to me.
:Remember, you'll have a lot of people coding on your MUD (at least if you
:want fast development). It seems like a good idea to prevent their code
:for having side-effects that are impossible to track.

Huh? I don't understand what you are referring to. What is terribly unsafe
programming? Perhaps you didn't follow what I was getting at. On entry
to a function, an array of "values" (union of all possible types) is
allocated (ignoring some optimizations), and a pointer to that array is
stored in the traceback record for the call. The slots are initialized
to parameter values or default values for the type of the local. During
execution, a local variable is referenced by using its fixed offset
into that array.

Hmm. I *think* I might know what you were getting at. No, I don't mean
other ways to reference locals behind the scenes - there are no
pointers or "reference" types. What I was trying to say was that you
don't need the name of a local to reference it at run time - the
interpreted code just needs the pointer to the current traceback
record, and the offset of the variable.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA