[erlang-questions] OO programming style in Erlang?

[Yariv Sadan]

> You could also use a macro, of course:
>
> -define(DICT, orddict).
>
> ?DICT:store(...)

Related to the macro advice, it should probably be mentioned that if
the type of the module isn't known until runtime, Erlang lets you use
an atom variable in place of the module and/or function name, with a
(small?) performance cost. E.g., assuming Module and Function are
atoms, this is legal:

foo(Module, Function, Param) ->
  Module:Function(Param).


>
> 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.
>

I have run into few cases where module extension was so desirable I
wished it were part of the language. Since it wasn't, I implemented it
in Smerl, but it's not as user-friendly as a language feature would
have been. At the minimum, you would have to call

{ok, M} = smerl:for_module(MyModule),
M1 = smerl:extend(BaseModule, M),
smerl:compile(M1).

ErlyWeb uses this feature in a few places, but one of the reasons it
works well is that ErlyWeb compiles application modules for you, so
you don't have to worry about using Smerl directly.

It wouldn't be very hard to respin the Smerl code into a parse
transform, so if you wanted a child module to extend a base module,
you could write in the child module

-parse_transform(extend, [BaseModule]).

but since the ErlyWeb compilation mechanism was sufficient for me I
haven't done it :)

Best regards,
Yariv