private keyword dont appear to do anything

[H. S. Teoh]

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.