Erlang hints for an OO junkie

[Chris Pressey]

On Thu, 12 Aug 2004 06:34:09 +0200
"Johan Warlander" <johan@REDACTED> wrote:

> On Wed, 11 Aug 2004 14:44:13 -0700, Chris Pressey wrote
> > > The thing is that you can seldomly rely on anything at all to be
> > > non-dynamic in a game. However, one thought I had was if perhaps
> > > the objects/items as such- even persons and windmills - should be
> > > indeed records, and the behaviours themselves be the processes,
> > > attaching to the appropriate record.
> > 
> > This works too.  Each record can have a field for its "animacy", 
> > which might be a process or might be absent.  What this appears to 
> > be leading towards is modelling everything as partly static, partly
> > dynamic.
> 
> Yes, exactly -- that would be one approach at least, and how well it
> fits for my purposes? Don't know yet, but hopefully it'll become more
> apparent after some experimentation.

Actually, I'm now guessing it'll work nicely.  All your accessor
functions can take a record.  They look at the "process" field, if it's
a valid pid, they message the process for information and wait for the
reply.  If it's the atom "undefined", they look at the other fields in
the record instead.

"Animating" an object would involve simply taking its record from the
database, starting a process for it, giving the process a copy of the
record for its internal state, then writing the pid of the process back
into record in the database.  "De-animating" it would be just the
reverse: killing the process and putting its internal state back into
the database record (with no more pid.)

> > When an actor speaks, a message is sent to the room they are 
> > currently in.  Each room keeps track of all the actors in it, so it 
> > relays each of them the same message.  If the message was "loud",
> >  perhaps the room sends it to all adjacent rooms as well.
> 
> Yup, and each container might filter the message as it passes through
> - if someone's hiding in the closet, some words might come out
> garbled, and if the door to the next room is closed, you might need to
> listen at the door to hear anything.

I hadn't considered those sort of things, but yes, they're the sorts of
things that would be fairly messy with the recursive search method.

> > Also, to go back to the subject of OO, it demonstrates a technique
> > (delegating) that can be thought of the parallel of inheritance in
> > a purely message-oriented system.  Instead of X IS-A Y, you have
> > something more like X RELAYS-TO Y.  This is much more flexible, but
> > since it's correspondingly easier for it to go haywire too, it's
> > likely that it should be used even more conservatively/wisely than
> > inheritance should be used in OO systems.
> 
> Hmm.. I'm not sure if I see the parallel so clearly, but I might be
> missing something - and it does seem a little more dynamic to me, as a
> recipient doesn't have to pay attention to the message, or even know
> about it (as long as message queues are properly flushed).

The parallel is admittedly, um, strained :)  I'm thinking along the
lines of, what if you had to implement inheritance but you only had
messages and processes to do it with?  Why, you'd have a Cat process,
and a Mammal process, and an Animal process, and any message Cat
receives that it doesn't understand, it sends off to Mammal and waits
for a reply which it sends back to whoever asked it in the first place -
ditto Mammal and Animal.

Of course, these are instances, not classes, so if Mammal contained any
state, you'd need one Mammal process for each Cat process and so on.

Definately not a model you want to use in production code; I just think
it's interesting to think about the possibilities... e.g. could you have
two processes with each being the delegate of the other?  Would multiple
delegation have any benefits over multiple inheritance?  etc etc  :)

-Chris