On Tuesday, 15 May 2018 at 05:59:44 UTC, Mike Parker wrote:
Jonathan's right. We're just not going to agree on this.
The purpose of discussion is not necessarly to get one side to
agree with other side.
You can keep your grouping and get your strict encapsulation
like so:
// foo/bar/baz/package.d
module foo.bar.baz;
public import
foo.bar.baz.a,
foo.bar.baz.b,
foo.bar.baz.c,
foo.bar.baz.funcs;
The client need neither know nor care that everything is in
separate modules and you get your strict encapsulation. You can
still share items between modules via package protection, and
within specific package hierarchies via package(packageName).
And even better, you now have less code per module to reason
about (re: one of your earlier arguments against the current
behavior).
Fine. If I take your solution above, and ensure that every class,
goes into it's own module, and that a module containing a class,
contains nothing other than a single class (i.e no free
functions), then sure, I end up where I am now, with C++/Java/C#
- i.e a good place, where I feel comfortable. My declared
interface is respected.
Why do I need D then? i.e. under what circumstances, would I want
to put something extra into the module, so that it can abuse the
declared interface of my class?
Can you give me some examples?
