[Haskell-cafe] Observer pattern in haskell FRP

[Nathan Hüsken]

On 12/12/2012 01:26 AM, Ertugrul Söylemez wrote:
> Nathan Hüsken <nathan.huesken at posteo.de> wrote:
> 
>>> Actually it is very scalable, as the same map is passed to every
>>> object. It can even live in the underlying monad, which means that
>>> you could even use a mutable vector, if you wish; however, I don't
>>> recommend that.
>>>
>>> Remember that a map is immutable and shared, so passing the same map
>>> to multiple objects is in fact the same as passing a pointer in
>>> C++. Lookups in and updates to the map are of logarithmic
>>> complexity, so this scales well.  Only doubling the number of nodes
>>> actually adds one full step to lookups and updates.
>>>
>>> If you're dealing with millions of objects you may want to use the
>>> vector solution mentioned earlier.  This requires an imperative
>>> underlying monad, but you would get about the same speed as in C++.
>>
>> I might just not be used enough to functional data structures, "Purely
>> functional data structures" is on my reading list :).
>>
>> I was thinking, in the asteroids example the only reason why the view
>> needs more input than the models output, is that it needs to be
>> informed of creation and destruction of asteroids.
> 
> Why would the view need to be informed?

So that the coresponding view objects can be removed (imidiatly or at
some later point).

> 
> 
>> So, in the model one could habe a signal
>>
>> asteroidsModel :: Signal Input [Just AsteroidModel]
>>
>> which outputs "Nothing" for asteroids that have been destroyed.
>> Then, in the view this would be taken for as input for
>>
>> asteroidsView :: Signal [Just AsteroidModel] [Picture]
>>
>> asteroidsView would have to do the following:
>> * route the input list to a list of "asteroidView" signals.
>> * When there is a "Nothing" in the input list, the corresponding (now
>> exploding) view is moved to a list of "zombie asteroids" where it
>> remains until its explosion animation is over.
>> * When the input list is longer than the list of current astroidView
>> signals, the list is extended.
>>
>> This would avoid the need for bookkeeping ids.
> 
> This is a very complicated way to do it.  I would simply regard the
> "zombie asteroids" as regular objects.  That way you don't need a
> special case in the view.

I was thinking by doing it this way I could completely avoid the need
for ids by this the bookkeeping of ids.
On the other hand, I might need the ids anyway for other things and than
my approach would just add complexity, as you said.

Regards,
Nathan