[erlang-questions] Erlang modelling question

[Damien Morton]

You're probably over complexifying things with multiple inheritance, 
hash tables etc.

And you can get different "methods" by pattern matching in the handler.

agent ! { rub_tummy, { gently, with, hand} }

crocodile:handler({rub_tummy, { X, with, Z}} -> eat(Z).
cat:handler({rub_tummy, {gently, Y, Z}}) -> purr().
cat:handler({rub_tummy,X}-> scamper_off().
cat:handler({bark_at}) -> scamper_off().

So your problem is one of code management - Darius, who frequents this 
list sometimes, pointed out that its an instance of the expression 
problem. see http://www.daimi.au.dk/~madst/tool/papers/expression.txt

I reckon that you're probably better off not worrying about inheritance 
at all. Instead, draw up a grid - along the top write down the kinds of 
agents you have (cat, dog, crocodile), and along the side write down the 
kinds of stimuli they can get from the environment. In the cells of the 
grid, write your code. If any code is shared, so much the better.




> Hi,
>
> thanks for the advice, it did not know that pattern (I found its
> description in http://en.wikipedia.org/wiki/Decorator_pattern).
>
> I think the behaviour you described could be implemented in a very
> similar way to the aforementioned multiple inheritance : leaf to roots
> traversal with handler look-up based on message-specified method/handler
> name.
>
> This could be done at runtime for a versatile system or maybe at design
> time with kind of per-class (per-module) prebuilt hash-tables, quite
> similar to, say, C++ virtual tables.
>
> I will try one of these two options (the former first, if it does not
> kill performance too much) and maybe come back with some result to share.
>
> Thanks for your help,
>
> Olivier.
>
> Damien Morton a écrit :
>   
>> 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,
>>>
>>> Olivier.
>>>
>>> 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 * <olivier.boudeville@REDACTED
>>>> <mailto:olivier.boudeville@REDACTED>> wrote:
>>>>
>>>>     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.
>>>>
>>>>
>>>>         
>
>
>