[erlang-questions] Please help me relate a past project to Erlang, I'm trying to understand...

[Thomas Lindgren]

----- Original Message ----
> From: bill robertson <billrobertson42+erlang@REDACTED>
> To: erlang-questions@REDACTED
> Sent: Friday, March 13, 2009 12:26:20 AM
> Subject: Re: [erlang-questions] Please help me relate a past project to Erlang, I'm trying to  understand...
> 
> So I've been thinking more about Erlang lately, and I still haven't
> gotten over a conceptual hurdle.  Where do you keep state?
> 
... 
> In the Erlang world, I can easily see how you would want a process for
> the conference call, and possible a process for each participant.  I
> also understand that you don't want to use a process local map for
> storage.  So would you use an ets or a dets table?  Or would you track
> it in a completely different fashion.
> 
> I would really appreciate your help.


As others have mentioned, the simplest way is to keep the data in a process. For instance, you can naively map an object to a process by a scheme like this:

start() ->
   obj_loop(1, "hello", ...).   %% initialize the process

%% process one message:
obj_loop(F1, F2, ..., Fn) ->
  receive
   {set_f1, NewValue} ->
        obj_loop(NewValue, F2, ..., Fn);
   {get_f1, Asker} ->
        Asker ! F1,
        obj_loop(F1, ..., Fn);
   {method_1, A1, ..., An} ->
        ... operate on fields, yielding New_F1, New_F2 say ...
        obj_loop(New_F1, New_F2, F3, ..., Fn);
  end.

Each of the cases ends in a tail recursive call to obj_loop/N, which will be implemented as a loop. Method calls are implemented by sending and receiving messages. (In practice, you often want to pass along the sender's PID as well as do other stuff, but the general principle is the above.) And remember that this is naive; you probably shouldn't try to do it for all data structures, just for the "natural" processes of your problem.

Moving on, you could also look at the gen_server module, which is a variation on the above approach that abstracts away some of the cruft. Using ets and dets for storage can be helpful for other reasons, such as reliability, but complicates things.

I'd suggest you begin with one process per caller and a coordinator process and see where that ends up. For simplicity, register the coordinator process by name so that the callers easily can find it.

Best,
Thomas