[erlang-questions] Module dependencies - from newbie

[Ladislav Lenart]

Francis Stephens wrote:
> I am currently having a problem finding a good way to manage some module 
> dependencies.
> 
> I have a single module which called 'formula'.  It looks very similar to 
> the core dict module which allows users to create, query and modify 
> their dict datastructures.  My formula module allows users to create, 
> query and modify boolean formula.
> 
> However, I am currently experimenting with different internal data 
> structures for the formula module and would like to be able to swap them 
> in and out of my program easily.  Currently there are a number of 
> different modules which make function calls to the formula module and it 
> seems that I would have to go and edit each function prefix for every call.
> 
> My current options seem to be to me
> 
> 1: Add a macro which will change the prefix for me at compile time.
> 2: Write each prefix as a Variable (Prefix:fun()) and pass in the 
> appropriate module with each function call.  I believe those calls are 
> significantly slower than non-variable prefixed function calls.
> 
> 3: reorganise my code in a more sensible way.
> 
> Currently I am still thinking about the code organisation in a very OO 
> way and if there is a good Erlang approach to this kind of problem I 
> would love to learn about it.

Hello,

I am not sure I understood you correctly so I rephrase your question using
an example:

You are about to write a module M that uses a dictionary as part of its internal
structure. Erlang library already provides two dictionary implementations: dict
and orddict. You want to make it easy for M to change from one to another providing
that both dictionary modules have the same interface (so the only changing bit
is the module name).

If your problem is similar to the one described above, I usually solve it with
macro because I am really interesting only in one implementation at a time.

If you want to use both implementations at the same time however, I would suggest
that part of the internal data representation associated with module M is a
dictionary module name and dictionary related functions are invoked using it.
I wouldn't worry about slowness until it is measured that it is the bottleneck.

HTH,

Ladislav Lenart