[erlang-questions] Decomposing Modules

[Garrett Smith]

Without spending much time on this, my first impression is that you
may want to decouple the gen_server implementation from the data
structure implementation. These are probably separate concerns.

The gen_server deals with state initialization and mutation for
processes. The data structure implementation is a bunch of pure
functions.

On Thu, Nov 12, 2015 at 3:58 PM, Judson Lester <nyarly@REDACTED> wrote:
> Yeah, so, for my sins:
> https://git.lrdesign.com/judson/ergo/blob/master/src/ergo_graphs.erl
>
> On Thu, Nov 12, 2015 at 1:53 PM Judson Lester <nyarly@REDACTED> wrote:
>>
>> It's the depgraph manager for a build tool. The module is >1000 lines,
>> with 280 function clauses, and shares some type specs and record defs
>> through a .hrl.  The project isn't public yet, but maybe I should get over
>> that.
>>
>> On Thu, Nov 12, 2015 at 12:05 PM Garrett Smith <g@REDACTED> wrote:
>>>
>>> What's an example of a really large module that is triggering your
>>> spidey senses?
>>>
>>> On Thu, Nov 12, 2015 at 12:48 PM, Judson Lester <nyarly@REDACTED> wrote:
>>> > I suspect I'm not alone in having modules that grow to unwieldy sizes.
>>> > I'm
>>> > starting to understand better general classes of module that make sense
>>> > to
>>> > address, but I'm wondering if there's advice about particular features
>>> > within a module that suggest how to separate functions into smaller,
>>> > more
>>> > module chunks.
>>> >
>>> > My slowly developing intuition is that it has a lot to do with the
>>> > parameters of the functions, and I get the sense that there's a gap in
>>> > my
>>> > understanding that'll make the decomposition easier. Maybe a
>>> > refactoring of
>>> > those parameters that'll make the separation more obvious?
>>> >
>>> > Judson
>>> >
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > erlang-questions@REDACTED
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>> >