[MUD-Dev] Embedded languages, object persistance... ack.

[Jay Carlson]

On Saturday, January 01, 2000 2:03 PM
"J C Lawrence" <claw at kanga.nu> wrote:

>   Consider a deep object heirarchy, where a large number of objects
>   which are in common use in the game all inherit from a common
>   shared object.  What happens if I come along and edit the methods
>   and/or attributes on that shared object?  What happens if I
>   totally redefine it?  What happens to all the objects that descend
>   from it?  What happens to the commands people have or are issuing
>   which affect the child objects?  What happens if the changes cause
>   mass breakages such that few to no objects actually work any more?

Cold and MOO have reasonable, well-defined answers to those questions.

The answer to that last question is: your fellow programmers form a lynch
mob.  How is that any different than checking in a bunch of busted changes
to CVS?

> For me some of the driving reasons behind internal languages are
> Rapid Application Development (implementing the game world or world
> features), suitability for non-professional programmer use, ability
> to tailor to world building versus general programming problems,
> ease of extending the language in "interesting" directions, and so
> forth.

Agreed, and add "useful multiauthor security".

> > So in general I know this code is to be compiled since you don't
> > want to be executing "scripts", but is this code an object? and
> > then is the byte-code stored? ack.. I'm confused.
>
> Not so fast.  The majority of MUD servers out there with internal
> scripting languages don't actually have an internal Virtual machine
> (VM) to which they byte compile their internal scripting languages
> (eg the Tiny-* clan).  Having a VM and building a byte code compiler
> can significantly increase performance, but it is also a non-trivial
> programming task that many have foundered on.

MOO got speed out of going bytecode, but the critical motivation was task
suspension.  In a straightforward tree-descent interpreter, you end up with
continuation information sprayed all over the C stack; if you want to, say,
block the currently executing method and wait for a line of input from the
user, you'd have to save the C stack and later restore it when the line was
available.  Ew.

The work involved in explicitly managing all the activation records on a new
explicit stack was probably about the same as doing the full rewrite to
bytecode.

> Another distinction which needs to be made here (which most of the
> object oriented servers fail to do) is between a class definition
> and an object.

I think you've wandered into an old argument with both arms flailing.
Although most mainstream languages are class-based, a lot of important
languages and theoretical work are object-based.  Cardelli's page at
http://www.luca.demon.co.uk/ has many interesting links; see in particular
http://research.microsoft.com/Users/luca/Slides/PLDI96Tutorial.pdf for many
of the issues outlined in one place.  Cardelli forcefully argues that
class-based systems are strictly less expressive than object-based systems.

> A class definition describes and defines how
> something would be and would work if it existed.  It _defines_
> something, it doesn't actually create one of those things.  An
> object is an "instance" of a class.  It is a created example of the
> class definition.

> Why is this important?  In systems which make a distinction between
> classes and objects, you can compile the class definitions and store
> the results with with class, and then merely have the various object
> instances refer to that definition to access their defining code.

This is a red herring.  Object-based language implementations can and do
perform this kind of optimization without the model restriction required by
classes.

> You can also build different systems to handle class definitions
> than you use to handle objects, tailoring each system to handle its
> data type (class or objects) best and not the other.

If this is being argued as an advantage of the class-based model, I think
this begs the question.

> However, most current MUD servers do not define the difference
> between a class definition and an object instance.  They are one and
> the same.  (eg MOO, ColdC, etc).  What this means is that an object
> usually also defines its class.

No.  A MOO object defines its *behavior*, often in terms of delegation to a
parent object.

(Sidetrack: MOO frobs were a little like instances of classes described by
MOO objects; Cold borrowed them.  Ben Jackson's WAIF proposal carries this
much further.)

> Often programmers for such systems
> try and install an artificial distinction by only doing programming
> (class definitions) in objects that they never actually use
> anywhere, and just inheriting children from those object when they
> want to create intantiations (ie the objects players actually use).
> Not making the distinction makes things simultaneously a little
> messier and a little easier in implementing the system.  You now
> have only one type of thing to deal with (objects), but you now also
> have to deal with a mess of class heirarchies amd objected
> heirarchies which are intermingled.  Depending on how you approach
> things, the difference can be large or quite small.

I haven't seen many examples in the MOO world where this has been an ongoing
problem.  Singleton "real" objects (like swords and exits) frequently get
new behavior, but people tend not to create children of them.  There is a
strong distaste in some parts of the community for not following a strict
prototype/instance distinction, but it's sure come in handy from time to
time.

(For a while, some people changed their parent object to *me* on LambdaMOO.
I was asked to disallow that because it could be used for quota scamming,
and the wizards involved thought it would be a lot easier to ask me to stop
than to go bug hunting.)

> > Here, I'll try to demonstrate what I little I think I know from
> > MUSH type enviroments. A MUSH allows you to create an
> > object. Great. This object is unique and persistent. Ie. it will
> > be there when you get back if you so desire. You can assign code
> > to execute based upon certain defined actions on the object, or
> > you can create a new action for this object. Going by this model
> > then, does that mean every single object in these "new" muds is a
> > class and is inherited from a previous object? But then it's
> > executed how?
>
> See the above dinstinction between classes and objects.  MUSHes fail
> to make that distinction and thus every object has the potential to
> both be an object _and_ a class definition for other objects and
> classes.
>
> Yes, it is kind of confusing if you come from a strict OO
> background.

Only if your strict OO background isn't very broad.  :-)  No, I know what
you're trying to get at, but I think "mainstream OO" would be a better fit.

> > -doesn't require me to learn it's "own custom embedded
> > language"...
>
> Realise that no matter what language it uses, for someone it will
> require learning a whole new language as they won't know it.
> Doesn't really matter if its Java, Python, NetREXX, or whatever.
> The advantage with chosing a generic programming language here is
> that your audience of people who do know it increases, and they have
> some chance of being able to exploit that skill elsewhere as well.
>
> Note however that once you have a language chosen, the real learning
> pain is in your class heirarchy -- which is expressly NOT portable
> and NOT leveragable to other systems.

Absolutely.  Here's a concrete example.  Suppose you're using a restricted
Java subset as your extension language.  You probably do *not* want to have
java.util.Vector easily available; whenever  Alice's code returns a Vector
to Bob's code, Bob can mutate it.  Gosh, I hope that wasn't a skill list....
This is patchable by adding authorization tests to the Vector class, but
then you have to teach your builders how Java-with-controlled-Vectors works,
ad infinitum.

Jay




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