std.compress

Jakob Ovrum jakobovrum at gmail.com
Tue Jun 11 11:22:25 PDT 2013


On Tuesday, 11 June 2013 at 13:13:56 UTC, Daniel Murphy wrote:
> Also, compress is a ridiculously general name for a function.

We have module-level functions called "copy" (multiple), "read", 
"write", "map", etc. already, and it's not a bad thing!

It's OK because the full name is not "compress", but 
"std.compression.lz77.compress". This way, how specific the code 
wants to be depends on the user and the particular use-case, 
instead of one-size-fits-all alternatives like "lz77Compress". 
There's no redundancy in the name yet we still have the option to 
be pin-point specific (e.g. static import), and yes, we still get 
to use UFCS!

To eliminate the UFCS problem - which doesn't happen very often 
(how often do you want to use two different compression 
algorithms in the same unit?), we can (must?) use renamed symbols 
when importing.

Since any example using multiple "compress" functions would be 
contrived, I'll use an existing conflict - the case of "copy".

The following program backs up the specified files and writes a 
nicely formatted message to stdout (OK, so a tiny bit contrived):
----
void main(string[] args)
{
	import std.algorithm : chain, copy, joiner;
	import std.array : empty;
	import std.file : fileCopy = copy; // `fileCopy` is std.file.copy
	import std.stdio : stdout;

	auto fileNames = args[1 .. $];

	foreach(fileName; fileNames)
		fileName.fileCopy(fileName ~ ".bak");

	if(!fileNames.empty)
		"Backed up the following files: "
			.chain(fileNames.joiner(", "))
			.copy(stdout.lockingTextWriter());
}
----

By eliminating redundancies from symbol names, we empower the 
user, and the module system offers all the tools necessary to 
solve conflicts in a variety of ways.


More information about the Digitalmars-d mailing list