[erlang-questions] OO programming style in Erlang?

[Ulf Wiger]

Den 2007-01-22 11:52:35 skrev Ladislav Lenart <lenartlad@REDACTED>:

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

As far as possible, try to separate side-effect free code
 from that with side-effects. Typically, at least 90% of
your code can be made side-effect free, and it's a good
idea to really isolate the remaining 10%.

This also affects your interface design. Try to make
sure that your interfaces do not mandate side-effects.
Compare e.g. dict.erl and ets.erl

ets:insert(Tab, Obj) -> true   % mandates side-effects
dict:store(Key, Value, Dict1) -> Dict2       % doesn't


> 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
>
>    orddict:new()
>    orddict:store(...)
>
> 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.

A fairly common solution to this dilemma is to use
your own wrapper functions

dict_new() ->
    orddict:new().

etc.

You could also use a macro, of course:

-define(DICT, orddict).

?DICT:store(...)

but I much prefer the wrapper function.
One reason is that ?DICT can really be any
syntactic expression, so anytime a macro is
used, the reader has to make sure he/she knows
what's hidden behind it.



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

No universally agreed upon common method, no,
if I understood your question correctly.

Xmerl, for example, introduced a notion of module
inheritance, with which one were supposed to extend
the functionality of export callbacks. See e.g.
http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/xmerl/src/xmerl.erl?revision=1.2&view=markup
mainly lines 267-313.
(or the OTP source tree for a more current version.)

I don't know if anyone has actually made use of it.

BR,
Ulf W
-- 
Ulf Wiger