"David Nadlinger" <code@klickverbot.at> wrote in message news:gzniyhyeuhjturqffgan@forum.dlang.org...
> On Thursday, 13 June 2013 at 23:45:12 UTC, Daniel Murphy wrote:
>> I don't think 4 characters is a high price to pay for the added clarity.
>> Then there is no ambiguity, no need to rename imports, no problems using
>> ufcs.  Every time I see lz77Compress in anybody's code I know exactly
>> what
>> it does!
>
> import std.compression : lz77Compress = lz78Compress;
>
> ;)

:(

On 2013-06-14 01:53, David Nadlinger wrote:

> import std.compression : lz77Compress = lz78Compress;
>
> ;)

If you do that you only have yourself to blame. What if someone uses monkey patching and replaces all your functions at runtime.

-- 
/Jacob Carlborg

On Thursday, 13 June 2013 at 23:45:12 UTC, Daniel Murphy wrote:
> I don't think 4 characters is a high price to pay for the added clarity.
> Then there is no ambiguity, no need to rename imports, no problems using
> ufcs.  Every time I see lz77Compress in anybody's code I know exactly what
> it does!

I recommend you just use local imports if it bother you that much, then it's obvious:

import std.compression.lz77;
auto newdata = compress(data);

Really, it should be obvious from the context which compression algorithm you are using.


> I understand the motivation for shortening function names that will be used
> frequently... but this is not in that category.

This is not the motivation. The problem with lz77compress is that it is redundant:

std.compression.lz77.lz77compress

It's bad style to repeat the module name in module identifiers. It completely defeats the purpose of using modules as namespaces.

If all the compression algorithms were inside std.compression instead of having their own modules then yes, lz77compress would be a fantastic name, but they're not, so it's not.