[erlang-questions] Erlang modelling question

[Olivier Boudeville]

Hi,

it is a kind of POO-related question (I guess lots of Erlang newcomers
have trouble making abstraction of their POO habits !). I read several
past threads on close subjects and Joe Armstrong book, but I could not
really find a satisfactory solution to my problem : I would like to
simulate a distributed system with plenty of actors interacting
concurrently. For this reason and many others, Erlang for sure should be
an interesting implementation language.

My problem is that most objects share behaviours at different levels. At
least in a POO-way of modelling, the obvious solution would be to
represent them as active objects whose classes would be defined through
rather deep inheritance trees. This is not an artificial way of
considering the reality : they are indeed linked with "is-a"
associations. Not depending on the modelling approach X is really a
specialized Y which itself is a specialized Z, they share both data and
behaviours.

In Erlang, at least in my case study, I believe these instances should
be processes, classes should be mapped to modules and events to
messages. As code duplication should be avoided, when I have a MyX
instance-process of class-module X that receives a message that actually
should be handled by code factorized in Z, I must find a way to climb up
the hierarchy towards Z, either specified manually (hardcoded) or thanks
to an automatized method look-up.

Is such a mapping from a POO model to Erlang a non-sense ?
    - If yes, the modelling must be inadequate : how would the same
situation be modelled in an Erlang way ? (one could take creatures,
mammals, dogs for the Z, Y, X classes). My main concern is
developer-friendly code reuse
    - If no, I will end up implementing the multiple-inheritance case
mentioned in Joe's book, just suspecting I miss the point somewhere !

Again, I am not worried by encapsulation, polymorphism, etc., they can
be secured easily I think, I just search for a clean way of factorizing
code between similar concepts. If in addition I did not have to recode
by hand all the message-switching logic that would convey a request
received instances of each of the many specialized classes to the
relevant superclass...

Thanks in advance for any hint because I am really out of luck,

Olivier.