Erlang hints for an OO junkie

Johan Warlander <>
Mon Aug 9 23:19:28 CEST 2004

<oops.. managed to cut that one off.. here goes; sorry about the double post
before, experiencing some problems with my mail client!>

On Mon, 9 Aug 2004 21:26:00 +0200, Johan Warlander wrote
> > The basic premise in the paper is to think of data flows and 
> > processes rather than OO.  In OO an object is stored and represented 
> > in a single place with all the code that can access the data.  In 
> > erlang, messages are sent from process to process so data can be 
> > stored in whatever format is best for each process.  You may neeed 
> > to keep things in a database, so you can have one table per object 
> > type, or coerce all to fit in a single table with some extra 
> > columns.  A process could read the currently relevant ones in as a 
> > list and dole them out to other processes for manipulation.  User 
> > commands can be received, transformed and routed to the process 
> > holding the object in question.
> I haven't even started looking at database handling etc.. I take it Mnesia
> would be the way to go? However, I definitely think I'd go for a 
> table per object type. Here's where I run into the OO ghost again, 
> though.. Given two different objects, a chair and a backpack, they 
> have some traits in common (in the OO world I'd have them inherit 
> from CONTAINER).. but

..but they might also have some data that is unique to each object, and some
ways of using one that would work different or not at all with the other. I've
not yet wrapped my mind around how to do proper data and code re-use in Erlang.


More information about the erlang-questions mailing list