On Wednesday, 5 June 2013 at 19:01:28 UTC, SomeDude wrote:
> On Wednesday, 5 June 2013 at 07:00:14 UTC, Jonathan M Davis wrote:
>> So, you want to create whole modules for each compression algorithm? That
>> seems like overkill to me. What Walter currently has isn't even 1000 lines
>> long (and that's including the CircularBuffer helper struct). Splitting it up
>> like that seems like over-modularation to me.
>>
>> - Jonathan M Daivs
>
> Well, as the author of a 15,000 lines datetime module, I think your opinion is a little biased.
>
> *I* think 1,000 lines is a perfect size for a module.

are cross module / file, inling working on all d compilers? if not, bigger modules are better.

On Wednesday, 5 June 2013 at 18:21:04 UTC, H. S. Teoh wrote:
> On Wed, Jun 05, 2013 at 01:20:48PM -0400, Jonathan M Davis wrote:
>> On Wednesday, June 05, 2013 14:02:37 Jakob Ovrum wrote:
>> > We have a standard library in disagreement with the language's
>> > encapsulation mechanics. The module/package system in D is almost
>> > ignored in Phobos (and that's probably why the package system
>> > still has all these little things needing ironing out). It seems
>> > to owe influence to typical C and C++ library structure, which is
>> > simply suboptimal in D's module system.
>> 
>> I honestly don't see how Phobos is in disagreement with the module
>> system. No, it doesn't use hierarchy as much as it should, and there
>> are a few modules that are overly large (like std.algorithm or
>> std.datetime), but for the most part, I don't see any problem with its
>> level of encapsulation. It's mainly just its organization which could
>> have been better. My primary objection here is that it seems
>> ridiculous to me create lots of tiny modules. I hate how Java does
>> that sort of thing, but there you're _forced_ to in many cases,
>> whereas we have the opportunity to actually group things together in a
>> single module where appropriate. And having whole modules with only
>> one or two functions is way too small IMHO, and that seems to be what
>> we're proposing here.
> [...]
>
> As Andrei pointed out, I think we need to look at this not from a size
> perspective (number of lines, number of functions, etc.), but from an
> API perspective: do these functions/structs belong together, or are they
> only marginally related? More precisely, if some user code uses function
> X, is that code equally likely to also use Y? Are there common use cases
> in which only Y is used, not X?
>
> If the use of function X almost always implies the use of function Y
> (and vice versa), then they belong in the same module. Otherwise, I'd
> say they are candidates for splitting up.
>
> If function X uses function Z, and function Y also uses function Z, but
> the use of X does not necessarily imply the use of Y (and vice versa),
> then I'd argue that X, Y, and Z should be in separate modules to
> maximize reuse and reduce the amount of code you have to pull in (you
> shouldn't be forced to pull in Z just because you use X which calls Y,
> which Z happens to also call).
>
> This may be a bit heavy-handed for user code, but for Phobos, the
> standard library, I think the bar should be set higher. After all, one
> of the stated goals of Phobos is that you shouldn't need to pull in a
> whole ton of code just because you call a single function. Right now I
> think we're a bit short of that goal.

Massive +1

Modules are for grouping functions/types that are commonly used together or have interdependencies, not for grouping things that are in a similar category (although these things can be related).

I don't care if levenshteinDistance is a "classic algorithm", I don't want to have to compile it every time I want to take the minimum of two numbers. Barely anyone is ever going to use it, so it should be off in a module on its own.

There's absolutely nothing wrong with having lots of small modules provided that you don't end up importing the same sets of modules over and over. There are numerous advantages:

1. Makes it easier to manage dependencies.
1a. reduces compile times.
1b. reduces binary size.
1c. benefits incremental and distributed/parallel compilation.
2. Makes version control easier as more files means merge conflicts are less likely.
3. Makes it easier to navigate files.

The only downside is that you may occasionally have to import more modules.

On Thursday, 6 June 2013 at 13:34:42 UTC, Xiaoxi wrote:
> are cross module / file, inling working on all d compilers? if not, bigger modules are better.

This is not at all relevant if either
 a) the functions in question are templates, as it is the case here
or
 b) the functions in a bigger module don't call each other anyway, such as in many kitchen-sink modules that just group vaguely related functionality together.

David

On Thursday, 6 June 2013 at 14:26:51 UTC, Peter Alexander wrote:
>
> Modules are for grouping functions/types that are commonly used together or have interdependencies, not for grouping things that are in a similar category (although these things can be related).
>
> I don't care if levenshteinDistance is a "classic algorithm", I don't want to have to compile it every time I want to take the minimum of two numbers. Barely anyone is ever going to use it, so it should be off in a module on its own.
>
> There's absolutely nothing wrong with having lots of small modules provided that you don't end up importing the same sets of modules over and over. There are numerous advantages:
>
> 1. Makes it easier to manage dependencies.
> 1a. reduces compile times.
> 1b. reduces binary size.
> 1c. benefits incremental and distributed/parallel compilation.
> 2. Makes version control easier as more files means merge conflicts are less likely.
> 3. Makes it easier to navigate files.
>
> The only downside is that you may occasionally have to import more modules.

Wise words !

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:koncgm$9f5$1@digitalmars.com...
> On 6/5/13 2:55 AM, Timothee Cour wrote:
>> What I suggested in my original post didn't involve any indirection/abstraction; simply a renaming to be consistent with existing zlib (see my points A+B in my 1st post on this thread):
>>
>> std.compress.zlib.compress
>> std.compress.zlib.uncompress
>> std.compress.lzw.compress
>> std.compress.lzw.uncompress
>
> I think that's nice.
>
> Andrei
>

This has the problem that you now can't import more than one compression module and still use ufcs.  The annoying one I keep hitting in phobos is std.file.write vs std.stdio.write.  For range-based APIs it is a huge pita to have to switch away from ufcs.  I think xyzCompress is still pretty sweet, consistent, and completely fixes the problem.  It has the added benefit that you can tell which compression algorithm is being used without having to know what is imported.

I would not have a problem with each module providing both 'compress' and 'xyzCompress', but that is against phobos policy.

On Sunday, June 09, 2013 17:12:16 Daniel Murphy wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:koncgm$9f5$1@digitalmars.com...
> 
> > On 6/5/13 2:55 AM, Timothee Cour wrote:
> >> What I suggested in my original post didn't involve any indirection/abstraction; simply a renaming to be consistent with existing zlib (see my points A+B in my 1st post on this thread):
> >> 
> >> std.compress.zlib.compress
> >> std.compress.zlib.uncompress
> >> std.compress.lzw.compress
> >> std.compress.lzw.uncompress
> > 
> > I think that's nice.
> > 
> > Andrei
> 
> This has the problem that you now can't import more than one compression module and still use ufcs.  The annoying one I keep hitting in phobos is std.file.write vs std.stdio.write.  For range-based APIs it is a huge pita to have to switch away from ufcs.  I think xyzCompress is still pretty sweet, consistent, and completely fixes the problem.  It has the added benefit that you can tell which compression algorithm is being used without having to know what is imported.

That can be fixed by using a local alias, but it's true that it's an extra annoyance.

- Jonathan M Davis

On 2013-06-05 16:31, John Colvin wrote:

> Agreed.
>
> To be honest, it's a trivial matter easily solved by a variety of tools,
> but I'm often just lazy and end up reading code with gedit or similar.

Gedit has a file tree sidebar, at least as a plugin.

-- 
/Jacob Carlborg

On Sun, Jun 9, 2013 at 12:53 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Sunday, June 09, 2013 17:12:16 Daniel Murphy wrote:
> > "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:koncgm$9f5$1@digitalmars.com...
> >
> > > On 6/5/13 2:55 AM, Timothee Cour wrote:
> > >> What I suggested in my original post didn't involve any indirection/abstraction; simply a renaming to be consistent with existing zlib (see my points A+B in my 1st post on this thread):
> > >>
> > >> std.compress.zlib.compress
> > >> std.compress.zlib.uncompress
> > >> std.compress.lzw.compress
> > >> std.compress.lzw.uncompress
> > >
> > > I think that's nice.
> > >
> > > Andrei
> >
> > This has the problem that you now can't import more than one compression module and still use ufcs.  The annoying one I keep hitting in phobos is std.file.write vs std.stdio.write.  For range-based APIs it is a huge
> pita
> > to have to switch away from ufcs.  I think xyzCompress is still pretty sweet, consistent, and completely fixes the problem.  It has the added benefit that you can tell which compression algorithm is being used
> without
> > having to know what is imported.
>
> That can be fixed by using a local alias, but it's true that it's an extra annoyance.
>
> - Jonathan M Davis
>

which is why I have suggested supporting UFCS with fully qualified function names:

auto a="".(std.path.join)("\n");
myfile.(std.file.write)(text);
text.(std.stdio.write);

see post: support UFCS with fully qualified function names (was in "digitalmars.D.learn") http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmars-d@puremagic.com

it also helps searchability: if one uses local aliases such as import std.stdio:write2=write, naive searching via grep 'write(' will miss such cases. The increase in complexity is minimal, and the feature makes sense with the rest of the language.

"Timothee Cour" <thelastmammoth@gmail.com> wrote in message news:mailman.999.1370827257.13711.digitalmars-d@puremagic.com...
>
> which is why I have suggested supporting UFCS with fully qualified
> function
> names:
>
> auto a="".(std.path.join)("\n");
> myfile.(std.file.write)(text);
> text.(std.stdio.write);
>
> see post: support UFCS with fully qualified function names (was in "digitalmars.D.learn") http://forum.dlang.org/post/mailman.1453.1369099708.4724.digitalmars-d@puremagic.com
>

I'm not a huge fan of this syntax.  If we were adding syntax, I would prefer a new operator with lower precedence than '.'

eg
auto a = "" -> std.path.join("\n");

But I'm not sure the problem is big enough to warrant new syntax.

> it also helps searchability: if one uses local aliases such as import std.stdio:write2=write, naive searching via grep 'write(' will miss such cases. The increase in complexity is minimal, and the feature makes sense with the rest of the language.
>

I agree, renamed imports make code harder to understand, and harder to refactor.

In this case we can prevent problem simply by not giving functions generic names like 'compress'.  Ideally you should be able to import the entire standard library with no name conflicts.

On Monday, June 10, 2013 11:44:56 Daniel Murphy wrote:
> In this case we can prevent problem simply by not giving functions generic names like 'compress'.  Ideally you should be able to import the entire standard library with no name conflicts.

We've actually made the opposite choice when discussing this in the past. We've specifically gone for making functions which do the same thing in different modules having the same name (e.g. std.ascii and std.uni), which makes swapping one for the other easy and avoids having to come up with distinct names, though it does obviously create more naming conflicts when you try and mix and match such modules. I'd also point out that it's been argued that it's a failure of the module system if we're specifically trying to avoid having different modules have functions with the same name. It's the module system's job to differentiate such functions, and specifically avoiding naming stuff the same to avoid naming conflicts means that you're pretty much ignoring the module system.

So, the general approach has been to name functions differently when they do different things and name them the same when they do the same thing and then let the module system take care of differentiating between the two when you need to.

- Jonathan M Davis