On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn wrote:
> <half-serious> Perhaps the solution is to go the one-overload-set-per-file route, with std/algorithm/package.d basically importing everything underneath. :-P </half-serious>
>
> (Shhh, don't tell Andrei, or we'll get another lecture about wasting time on worthless things while more important things are left to do.)

Actually, when Daniel and I were trying to talk Walter into adding the package.d feature so that std.datetime could be split up without breaking code, Walter made a comment about how he didn't see any problem with there being a function per module. So, he might be on board with code arrangements along those lines, but I have no idea about Andrei.

Personally, I think that splitting stuff up that far makes it a pain to deal with, even if it might help the implementation sometimes. It's already really annoying that I have to figure out which module something in std.algorithm is in now, because the style check junk that has been added to Phobos requires that you not only use selective imports but that you use the module that it's directly in, so you can't do something like

import std.algorithm : map;

but instead have to go figure out which module it's currently living in and add that after std.algorithm.

Of course, I also don't generally have a problem with large modules. They _can_ become large enough to become a problem, but I've found that I have a much higher tolerance for how much goes in a single file than many of the D devs seem to have. IMHO, the main thing that starts causing problems with large modules is when you start doing stuff like using attribute labels like

@safe:

or attribute blocks like

@safe
{
}

because then it becomes difficult to know which attributes actually apply to a piece of code.

Most stuff is self-contained enough that having a bunch of stuff in a single module frequently isn't a real problem. So, if they're related enough, I have no problem with it. But good organization is arguably difficult to get right and highly subjective - just like naming stuff is.

Where you risk running into serious problems is where you have a large module full of interdependent stuff, because then it's all highly coupled and hard to keep track of, so it becomes hard to understand and maintain. You can have the same problems across modules, but when you split stuff up across modules, it tends to force you to think about things differently so that you don't make everything so highly coupled - though a bad programmer (or a good programmer having a bad day) can make any code a mess.

- Jonathan M Davis

On Fri, Nov 03, 2017 at 05:59:20PM -0600, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn wrote:
> > <half-serious> Perhaps the solution is to go the one-overload-set-per-file route, with std/algorithm/package.d basically importing everything underneath. :-P </half-serious>
> >
> > (Shhh, don't tell Andrei, or we'll get another lecture about wasting time on worthless things while more important things are left to do.)
> 
> Actually, when Daniel and I were trying to talk Walter into adding the package.d feature so that std.datetime could be split up without breaking code, Walter made a comment about how he didn't see any problem with there being a function per module. So, he might be on board with code arrangements along those lines, but I have no idea about Andrei.

I got chastised by Andrei for doing the std.algorithm split.  He only conceded after I stated that I couldn't run the std.algorithm unittests on my PC anymore because it was taking up GBs of memory.  Based on that I'm assuming he would likely be opposed to yet another refactoring of std.algorithm. :-D


> Personally, I think that splitting stuff up that far makes it a pain to deal with, even if it might help the implementation sometimes. It's already really annoying that I have to figure out which module something in std.algorithm is in now, because the style check junk that has been added to Phobos requires that you not only use selective imports but that you use the module that it's directly in, so you can't do something like
> 
> import std.algorithm : map;
> 
> but instead have to go figure out which module it's currently living in and add that after std.algorithm.

If we split everything into its own module, presumably the module would be named after the function itself, and would inherit directly from the top-level std.algorithm package.  So it would be a simple matter of going to std/algorithm/${function_name}.d to find the code, which arguably would be *simpler* than it is today.

But again, I'm not seriously proposing this, and I doubt we'd actually do it anyway.  The sheer amount of effort involved, plus potential user code breakage (explicit imports of std.algorithm.searching, for example, would break, unless we keep searching.d around as just a bunch of public imports, which is kinda ugly), yielding only marginal benefits.  I just don't see W & A approving of something like that.


[...]
> Where you risk running into serious problems is where you have a large module full of interdependent stuff, because then it's all highly coupled and hard to keep track of, so it becomes hard to understand and maintain.  You can have the same problems across modules, but when you split stuff up across modules, it tends to force you to think about things differently so that you don't make everything so highly coupled - though a bad programmer (or a good programmer having a bad day) can make any code a mess.
[...]

"Real Programmers can write assembly code in any language." :-D


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win are idiots.

On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:
> [...]

What's wrong with the introduction of another visibility attribute that behave like the C++ private?

Just curious...

---
Paolo

On Friday, 3 November 2017 at 12:43:15 UTC, rikki cattermole wrote:
> Visibility modifiers like private, and public are to the module not the scope.
>
> "Symbols with private visibility can only be accessed from within the same module."
>
> This is how module based languages work,

Pascal has "strict private". I like it because you can enforce the usage of setters and getters within the same module.

http://wiki.freepascal.org/User_Changes_3.0#.22strict_protected.22_visibility_modifier

To have strict privacy in D we have to isolate the "strict" thing in a file.

On Saturday, November 04, 2017 11:03:52 Paolo Invernizzi via Digitalmars-d- learn wrote:
> On Friday, 3 November 2017 at 23:32:52 UTC, H. S. Teoh wrote:
> > [...]
>
> What's wrong with the introduction of another visibility attribute that behave like the C++ private?
>
> Just curious...

Well, if a good enough DIP could be written to convince Walter and Andrei, then I'm sure it could be added, but it probably isn't worth it. If you really want that level of separation, then you can always just put your class or struct in its own module, and in practice, the fact that other stuff in a module _could_ access the private members of a struct or class doesn't tend to be a problem - and adding yet another access modifier does make the language and its implementation that much more complicated. It also might break existing code that uses type introspection and has logic based on what access level a symbol has.

Ultimately, while I don't think that there's any technical reason why we couldn't make such a change, I think that it's trying to solve a problem that doesn't really exist, and for the change to be made, a solid argument would have to be made as to why it's a real problem that needs fixing and why the proposed solution is the right one.

- Jonathan M Davis