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