<div dir="ltr">The further question, in my mind, is: does it make sense to split out the queries from the data structure? Or some of the utility stuff that transform representations of edges to and from statements for instance.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 12, 2015 at 2:04 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">Without spending much time on this, my first impression is that you<br>
may want to decouple the gen_server implementation from the data<br>
structure implementation. These are probably separate concerns.<br>
<br>
The gen_server deals with state initialization and mutation for<br>
processes. The data structure implementation is a bunch of pure<br>
functions.<br>
<br>
On Thu, Nov 12, 2015 at 3:58 PM, Judson Lester <<a href="mailto:nyarly@gmail.com" target="_blank">nyarly@gmail.com</a>> wrote:<br>
> Yeah, so, for my sins:<br>
> <a href="https://git.lrdesign.com/judson/ergo/blob/master/src/ergo_graphs.erl" rel="noreferrer" target="_blank">https://git.lrdesign.com/judson/ergo/blob/master/src/ergo_graphs.erl</a><br>
><br>
> On Thu, Nov 12, 2015 at 1:53 PM Judson Lester <<a href="mailto:nyarly@gmail.com" target="_blank">nyarly@gmail.com</a>> wrote:<br>
>><br>
>> It's the depgraph manager for a build tool. The module is >1000 lines,<br>
>> with 280 function clauses, and shares some type specs and record defs<br>
>> through a .hrl.  The project isn't public yet, but maybe I should get over<br>
>> that.<br>
>><br>
>> On Thu, Nov 12, 2015 at 12:05 PM Garrett Smith <<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>> wrote:<br>
>>><br>
>>> What's an example of a really large module that is triggering your<br>
>>> spidey senses?<br>
>>><br>
>>> On Thu, Nov 12, 2015 at 12:48 PM, Judson Lester <<a href="mailto:nyarly@gmail.com" target="_blank">nyarly@gmail.com</a>> wrote:<br>
>>> > I suspect I'm not alone in having modules that grow to unwieldy sizes.<br>
>>> > I'm<br>
>>> > starting to understand better general classes of module that make sense<br>
>>> > to<br>
>>> > address, but I'm wondering if there's advice about particular features<br>
>>> > within a module that suggest how to separate functions into smaller,<br>
>>> > more<br>
>>> > module chunks.<br>
>>> ><br>
>>> > My slowly developing intuition is that it has a lot to do with the<br>
>>> > parameters of the functions, and I get the sense that there's a gap in<br>
>>> > my<br>
>>> > understanding that'll make the decomposition easier. Maybe a<br>
>>> > refactoring of<br>
>>> > those parameters that'll make the separation more obvious?<br>
>>> ><br>
>>> > Judson<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > erlang-questions mailing list<br>
>>> > <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
>>> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>> ><br>
</blockquote></div>