[erlang-questions] OO programming style in Erlang?

Ladislav Lenart lenartlad@REDACTED
Mon Jan 22 11:52:35 CET 2007


I started to program in Erlang recently and have some "conceptual
issues" I am pretty sure you could help me with...

Suppose I have to write a piece of functionality. I can implement
this functionality in a library module fun_lib.erl which essentially
consists of two types of functions:
   * get_something(InternalState) -> something
   * set_something(InternalState, Something) -> NewInternalState

But I can as well implement this functionality in two modules,
fun.erl and fun_cb.erl where fun_cb.erl is a gen_server (or any
other behavior) callback module and fun.erl is the public interface
API for communicating with the process, i.e.:

   fun:something(Pid) ->
     gen_server:cast(Pid, something).

I could combine these two solutions as well by implementing fun_lib
module first and then implement fun_cb in terms of fun_lib.

*Question:* Based on what should I decide how a particular
piece of functionality should be implemented?

*Question:* Is this division recommended or should I put all these
parts (library, public process API and callback functions) to just
one module, fun.erl?

I have an OO experience and I like the basic ideas of encapsulation
and polymorphism but can not find a way how to materialize these in
my Erlang programs.

For example, there are dict and orddict modules which have compatible
(polymorphic) interfaces but differ in their implementations. This is
essentially good, but when I actually use one of these modules, my
code will look like


But this is bad because when I later decide to change (my) implementation
I actually have to go through my code and replace orddict with dict. So
this is not a polymorphism I am looking for.

Next problem (from this point of view) is pattern matching which commands
me to implement all the polymorphic behaviors in one module and implement
as many branches of each function as many different (but polymorphic)
behaviors there should be. But I don't like this because it means to modify
an existing module instead of extending it by writing a new (but polymorphic)
one next to it. According to this idea, there would be only one dict module
which would merge orddict and unordered dict (and any later) implementations...

*Question:* Is there a way such polymorphism can be achieved in Erlang
without actually merging (see above) the modules that should behave

Please don't take this as a critic of Erlang, but rather as a request of
an OO programmer to ease his transition to the new fascinating world of
concurrent programming...

Hints, tips and tricks are also welcome.

Thank you,

Ladislav Lenart

More information about the erlang-questions mailing list