On Monday, 22 October 2018 at 11:06:42 UTC, Jonathan M Davis
wrote:
On Monday, October 22, 2018 2:30:21 AM MDT Basile B. via
Digitalmars-d wrote:
On Monday, 22 October 2018 at 08:25:17 UTC, Andrea Fontana
wrote:
> Moreover: you're the author of the module so you're supposed
> to know how it works and which members you should call or
> not.
- team
- maintainer of a module written by someone that works
elsewhere
now.
that's two cases where strict privacy can be optionally a
thing avoiding wrong usage of private members within the scope
of a module.
Part of the point is that if the module is large enough that
the folks working on the code can't actually keep track of
what's in it, then it's too large, and as such, if you need to
protect your class or struct members from the rest of the
module, then it really should be in a separate module for the
code to be properly maintainable anyway. Yes, having multiple
people involved makes the problem worse (especially when some
of them join the team later), but it doesn't fundamentally
change the issue. If it changes anything, it simply makes the
argument stronger for preferring smaller modules so that
they're easier to digest.
Personally, I've found that larger modules have worked just
fine for me without having to worry about these sort of
encapsulation issues. It simply isn't a problem, and I don't
recall ever seeing a bug because of it. But anyone who's
worried about it always has the option of simply going for
smaller modules, and the encapsulation problem is already
solved without making the language any more complicated. Plenty
of folks already think that it's best practice te prefer
relatively small modules anyway, and if you need a way to
protect your private member variables from the module when the
module isn't large, then you're definitely doing something
wrong.
Given the D philosophy that the module is the primary unit of
encapsulation and that you should at least roughly understand
the entire module when working on it (or it's almost certainly
too large), having an access level to protect member variables
from the rest of the module simply makes no sense. Anyone who
feels the need for such an access level think about what
they're doing with their code and why they feel the need for it
- whether it's simply because they're used to it from other
languages, or because they're organizing their code in a manner
which is detrimental to maintainability.
- Jonathan M Davis
Here is the intial dip draft:
https://github.com/12345swordy/DIPs/tree/Encapsulation
If Walter Bright insist that the module is the unit of
encapsulation then I propose we get rid of the "one module per
file" restriction, by introducing sub modules.
-Alex
