<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 12, 2015 at 2:55 PM Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Could be :)<br>
<br>
If a set of functions stand out as forming a coherent interface for<br>
some common scenarios, that might be a candidate for a separate<br>
module. On the other hand, some modules are natural sinks for<br>
functions - e.g. erlang or an application 'util' module.<br>
<br>
For me, there's a clear separation of concerns between process<br>
management (e.g. gen_server) and data type manipulation (e.g. dict,<br>
graphs, etc.) Other concerns might deal with IO for a subsystem (e.g.<br>
database, service, etc.)<br>
<br>
I wouldn't really worry too much about this and let real pain drive<br>
your refactoring. There's no rule that says a module must be small or<br>
limited to N functions. There was even a proposal by a prominent<br>
Erlang programmer to get rid of modules altogether and just have a<br>
single global namespace for functions.<br>
<br>
You could experiment with various interfaces and see if that makes any<br>
difference to your understanding, usability, or maintainability of the<br>
software you're building. I would time box that though as you run the<br>
risk of over thinking this problem of keeping modules small. It might<br>
not be an actual problem.<br><br></blockquote><div><br></div><div>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" </div></div></div>