[erlang-questions] Decomposing Modules

[Garrett Smith]

I don't mind the scope of the module that you have there. It's
longish, but not unreadable.

I'd start by peeling apart the process concerns (state lifecycle and
interactions) with data structure related concerns. Data structure
here is not btw process state, but graph related operations.

That might be easier said than done in looking at the code - it's not
sure obvious where process ops and end and the others begin. I'd take
that step though for sure as it would clarify the concerns there quiet
a bit and should be fun. Life might go much easier with that one step.

On Thu, Nov 12, 2015 at 5:15 PM, Judson Lester <nyarly@REDACTED> wrote:
>
> 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"