std.compress

[Daniel Murphy]

"Jakob Ovrum" <jakobovrum at gmail.com> wrote in message 
news:fjmuuahorgbwkcvygnqq at forum.dlang.org...
> 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 is.

> 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!
>

There is a reason we don't call every function in phobos 'process' and let 
the module name tell us what is actually does - when you see the name in 
your source code, it is easy to recognize what is being done.

> 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.
>

My workplace has a fire extinguisher, but this doesn't mean lighting fires 
is a good idea.

I know we have the tools to disambiguate, but they come at a syntax and/or 
clarity cost.  Why create a problem when we don't have to?

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

Eg. Code which implements http compression with support for multiple 
algorithms.

tl;dr We have great tools to disambiguate when we have to.  Let's not have 
to.