std.compress
Adam D. Ruppe
destructionator at gmail.com
Wed Jun 5 10:29:25 PDT 2013
On Wednesday, 5 June 2013 at 17:10:38 UTC, Jonathan M Davis wrote:
> There's a balance to be had here that's
> somewhere in between the two extremes.
I think number of lines is the wrong thing to look at, at least
as the first measure.
The question I'd have is: is this of use to a different yet kinda
related concept? If yes, make it a module.
For example, in my code, the "struct Color" used to be defined
straight in simpledisplay.d. But image.d had its own struct
Color. I wanted to take image.d's Images and draw them on
simplediplay.d's Windows. But I didn't want either of those
modules to depend on each other. So now Color is in a separate
color.d and both use it.
Glancing at this code, the only not-strictly-related one is
CircularBuffer. You could argue it should be separate just
because it is of general use. But, is it needed for
interoperability? Would two separate modules need to pass the
same CircularBuffer type between them? If yes, separate it.
If no, now line count might be ok because the question I'd ask at
this point is: is it easy code? If so, the costs of adding
dependencies IMO override the costs of not being DRY (WETness???).
CircularBuffer here isn't exactly rocket science. I don't think
it passes the threshold to justify adding a dependency for it.
Whereas the compression algorithm itself does; if you were
writing a gif reader or whatever and implemented the algorithm,
I'd say split it into a module if some second module needs it
too. (Before then? do the simplest thing that can possibly work
and you ain't gonna need it, so I'd just keep it in the one file.)
More information about the Digitalmars-d
mailing list