[erlang-questions] Decomposing Modules

Judson Lester nyarly@REDACTED
Fri Nov 13 00:15:44 CET 2015

On Thu, Nov 12, 2015 at 2:55 PM Garrett Smith <g@REDACTED> wrote:

> Could be :)
> If a set of functions stand out as forming a coherent interface for
> some common scenarios, that might be a candidate for a separate
> module. On the other hand, some modules are natural sinks for
> functions - e.g. erlang or an application 'util' module.
> For me, there's a clear separation of concerns between process
> management (e.g. gen_server) and data type manipulation (e.g. dict,
> graphs, etc.) Other concerns might deal with IO for a subsystem (e.g.
> database, service, etc.)
> I wouldn't really worry too much about this and let real pain drive
> your refactoring. There's no rule that says a module must be small or
> limited to N functions. There was even a proposal by a prominent
> Erlang programmer to get rid of modules altogether and just have a
> single global namespace for functions.
> You could experiment with various interfaces and see if that makes any
> difference to your understanding, usability, or maintainability of the
> software you're building. I would time box that though as you run the
> risk of over thinking this problem of keeping modules small. It might
> not be an actual problem.
To be completely honest, what's happening is that I am feeling the pain,
but having a hard time seeing where to do the separation. I see the
*concerns* but not necessarily how to map that into "this one goes here,
that one goes there," but I guess the best answer may be "just try
something and see"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151112/73d62f90/attachment.htm>

More information about the erlang-questions mailing list