Erlang hints for an OO junkie

Johan Warlander <>
Tue Aug 10 21:31:27 CEST 2004

On Tue, 10 Aug 2004 20:03:02 +0200, Carsten Schultz wrote
> On Tue, Aug 10, 2004 at 08:34:19PM +0400, Vlad Balin wrote:
> > It's just fine, we succeed, we have a "class" queue defined now,
> > with a number of "methods".  But here is one problem remains.
> > Suppose we have defined another implementation of queue with a same
> > interface.  How would we define a generic function working with both
> > implementation then?
> > Problem is that we supposed not to have derect access to the data structure
> > of the abstract data type, so we need operations to be _polymorphic_.
> [solution snipped]
> I am not advocating this in any way, but you could also use a style
> like in the appended module, if you really have to.

Thanks to both of you for pointing out some other approaches :)

I'm wondering if the solution really is to find a middle road somewhere..
because the more I think of it, the more it seem like I'll need most of the
physical objects in the game world to actually be processes (or possibly group
some of them together to be managed by a single process). The reason is that
I'll need to propagate events. 

The example I used before is good enough I suppose - if someone in a room
talks, the sound will need to propagate into any container-like items in the
room as well (as appropriate) so that people sitting in a wagon, or hiding in
a chest or closet for that matter, will have a chance of hearing what the
person is saying.

Going further into the problem domain, eventually I will begin to model
Proximities, and those will be heavily dependent on the above interactions. A
Proximity in this context is strictly speaking a location *within* a room, for
 example one of the tables in a tavern. 

The way it'll work is that if people sit around one table and whisper
together, an outside observer in the same room will only be able to see/hear
that they are whispering, but not what. On the other hand, if they talk
normally, you'd actually be able to hear it.. and if they start shouting,
it'll easily come across into other proximities in the room (in this example,
people around other tables will hear them). 

I'm used to implementing this as a container without any physical obstructions
to the outside, since Proximities *do* essentially 'contain' people.

Of course, I don't know if there might a better way than using processes like
this, to perform that particular feat..


More information about the erlang-questions mailing list