[erlang-questions] Erlang modelling question

[Olivier Boudeville]

Yes, you are right, I will start with simple cases before introducing
dictionnaries and multiple inheritance. I will stay away too from the
Expression Problem, it would be overkill for my case !

Hopefully I will come back with a solution generic to some extent though.

Thanks,

Olivier.


Damien Morton a écrit :
> 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.
>>>>>
>>>>>
>>>>>         
>>
>>
>>   
>
>
>