[DGD] subdividing into subsystems

[Raymond Jennings]

it's mostly that I'm worried about turning into too much of a modularity
neat freak


On Tue, Apr 2, 2013 at 6:30 AM, James Smith <jgsmith at gmail.com> wrote:

> It depends on how the modularity affects execution, among other things.
> I'm a bit new to developing with DGD, but here's what I've noticed.
>
> I'm developing a mudlib on top of the kernel lib that divides up
> responsibilities roughly as outlined in some of the Skotos posts. I already
> tend to do data-oriented, event-driven development elsewhere, so this is a
> natural fit for me.
>
> Modularity can mean several things: separation of concerns (e.g., code
> that handles parsing goes in /usr/ToolLib while code that handles
> interpreting the parse results goes in /usr/DevLib), separation of
> execution threads (e.g., requesting a service from /usr/ToolLib requires
> queueing an event), and aggregation of functionality (e.g., a library
> managing bulk properties).
>
> What I've found so far is that separation of concerns and aggregation of
> functionality isn't a performance issue compared to separation of execution
> threads. As long as the code path is pretty clear and straightforward, it
> doesn't matter as much how many different users or inherited libraries are
> touched.
>
> The other thing I'm keeping an eye on is how may different objects have to
> be involved to get some operation done. If I can distribute information
> across many objects instead of concentrating it in a few (such as object
> relationships for containment and proximity), then (hopefully) the driver
> has more flexibility in which objects it keeps in memory at any one time.
> This seems like a good rule anyway when working with atomic functions.
>
> On Apr 2, 2013, at 8:05 AM, Raymond Jennings <shentino at gmail.com> wrote:
>
> > I've been on a modularization kick lately and I just split the main game
> > logic.  My latest move was to extract all object handling functionality
> > such as bulk, description, and so on to its own subsystem.
> >
> > Is there such a thing as excessive modularity when it comes ot a mudlib?
> > I'm starting to feel like I'm going crazy, but otoh having the kernel
> > library enforce privilege barriers as a perk is quite reassuring.
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>