[erlang-questions] Erlang modelling question
Sun Jun 24 02:50:20 CEST 2007
agent receives message
has list of possible handlers
works its was down the list calling each with the message, until one of
the handlers accepts the message and eats it
first one might be cat:handler, second one might be mammal:handler, last
one might be game_object:handler
think decorator pattern.
you get the added bonus that you can change your "inheritance hierarchy"
dynamically, e.g. by adding a magic_collar:handler as needed.
> Yes, it was what I tried to do, but I had no idea of *how* this could be
> done in Erlang : in my last post, you would choose the "yes" case, bad
> modelling for Erlang, ok, but what would be an appropriate modelling for
> that case ?
> So, let's say the problem is : simulate a multi-agent system with
> multiple kind of beasts, (including men, dogs, snakes, sharks, etc.)
> living in a given area and interacting.
> They are sharing obviously some behaviours, but showing some specialized
> features too. Whether or not this belongs to the problem (as for me I
> believe it is the case here), their organization into trees of species
> would make sense (i.e. it is more than an arbitrary way of thinking).
> Say, creatures include mammals that include in turn dogs, each
> categories factorizing features for all the subcategories it includes
> ("is a" relationship).
> How such a problem could be mapped into Erlang concepts ? How would you
> model the situation, knowing that each creature can live, move and die,
> that mammals are indeed specialized creatures that have backbones, and
> that dogs are specialized mammals with four legs and a tail ?
> What I would like is to avoid the developer having to hardcode by
> himself the implied inheritance between actors : when adding a cat in
> the simulation, I would like to specify 1. it is a specialized mammal,
> 2. what are its specific traits, but not that a cat has a backbone and
> it can live, move and die.
> Thanks in advance for any hint,
> Val Functor a écrit :
>> It looks like you have one extra level of indirection:
>> problem concepts -> 1990-2005 OO concepts -> Erlang concepts
>> Drop the middle layer.
>> Take the problem and map it to your tool, Erlang in this case.
>> Purposely going through the middle layer is an artificial problem.
>> The best way to solve those kind of problems is not to.
>> On 6/21/07, *Olivier Boudeville * <
>> <mailto:>> wrote:
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
>> code between similar concepts. If in addition I did not have to
>> 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,
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions