"Jakob Ovrum" <jakobovrum@gmail.com> wrote in message news:sdgqfozqnysbnumynkvp@forum.dlang.org...
> On Tuesday, 11 June 2013 at 22:34:55 UTC, Daniel Murphy wrote:
>> 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.
>
> "copy", "write" and "compress" are perfectly recognizable names.
>

Ok, how exactly is the data compressed in the following snippet?  No scrolling up to the top of the module to see what's imported!

newdata = data.compress();

>> tl;dr We have great tools to disambiguate when we have to.  Let's not
>> have
>> to.
>
> The way I see it, you're asking that all code should pay for the benefit of a minority of cases. I'd choose the inverse.

This is not a function that will be used every few lines.  Making the name a little longer for an increase in clarity is usually seen as a good idea.

On Thursday, 13 June 2013 at 11:36:16 UTC, Daniel Murphy wrote:

> Ok, how exactly is the data compressed in the following snippet?  No
> scrolling up to the top of the module to see what's imported!
>
> newdata = data.compress();

You can have that argument for any single overload and virtual call. At least you know it statically; with virtual you don't know until runtime... In many languages you would have interface ICompressor { Stream compress (Stream s) }...

On Thursday, 13 June 2013 at 11:36:16 UTC, Daniel Murphy wrote:
> Ok, how exactly is the data compressed in the following snippet?  No
> scrolling up to the top of the module to see what's imported!
>
> newdata = data.compress();

If it's not obvious from the context, just be explicit.

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

Don't force verbosity on everyone just in case someone wants it.

On 6/13/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> If it's not obvious from the context, just be explicit.
>
> newdata = std.compression.lz77.compress(data);
>
> Don't force verbosity on everyone just in case someone wants it.

What happens when we get std.compression.lz78 and you end up accidentally calling compress on with lz77 and expand with lz78? Pseudocoding:

module deserialize;
import std.compression.lz77;
auto readfile(string filename) { return readFile(filename).expand; }

module serialize;
import std.compression.lz78;  // oops!
void writeFile(T)(T[] data, string filename) { writeFile(filename,
data.compress);  }

Imports are incredibly easy to screw up. But if we used types instead of global modules then we could not only make our calling code clearer (and less buggy), but it would also allow us to use package imports so we can use any compression algorithm:

module deserialize;
import std.compression;  // package import, e.g. imports lz77, lz78, etc modules
auto readfile(string filename) { return filename.readFile.lz77.expand; }

module serialize;
import std.compression;  // package import
void writeFile(T)(T[] data, string filename) {
data.lz77.compress.writeFile(filename); }

"lz77" would be an auto function which takes the buffer and returns a Lz77 struct that has expand/compress methods.

On 6/13/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> But if we used types instead of global modules

*global functions*

On Thursday, 13 June 2013 at 13:15:03 UTC, Andrej Mitrovic wrote:
> What happens when we get std.compression.lz78 and you end up
> accidentally calling compress on with lz77 and expand with lz78?

The exact same typo could happen with your structs. You haven't solved anything:


> module serialize;
> import std.compression;  // package import
> void writeFile(T)(T[] data, string filename) {
> data.lz77.compress.writeFile(filename); }

void writeFile(T)(T[] data, string filename) {
    data.lz78.compress.writeFile(filename);
}

oops!

On Thursday, 13 June 2013 at 13:15:03 UTC, Andrej Mitrovic wrote:
> What happens when we get std.compression.lz78 and you end up
> accidentally calling compress on with lz77 and expand with lz78?
> […]
> Imports are incredibly easy to screw up.

I think this argument is invalid: A typo in an import statement is just as likely as in a function call.

David

On Thursday, 13 June 2013 at 11:36:16 UTC, Daniel Murphy wrote:
> Ok, how exactly is the data compressed in the following snippet?  No
> scrolling up to the top of the module to see what's imported!

I don't need to scroll to the top of the module, just a few lines up because I'm using function-local imports anyway. :P

If you want extra verbosity (which can be good *sometimes*), just write "import lz77 = std.compression.lz77" and you are good to go.

David

"David Nadlinger" <code@klickverbot.at> wrote in message news:ahqzxzjbhmfiacwjgfkj@forum.dlang.org...
> On Thursday, 13 June 2013 at 11:36:16 UTC, Daniel Murphy wrote:
>> Ok, how exactly is the data compressed in the following snippet?  No scrolling up to the top of the module to see what's imported!
>
> I don't need to scroll to the top of the module, just a few lines up because I'm using function-local imports anyway. :P
>
> If you want extra verbosity (which can be good *sometimes*), just write "import lz77 = std.compression.lz77" and you are good to go.

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 understand the motivation for shortening function names that will be used frequently... but this is not in that category.

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;

;)