On Wednesday, 15 February 2023 at 08:57:27 UTC, Mike Parker wrote:
On Wednesday, 15 February 2023 at 08:56:00 UTC, Mike Parker
wrote:
If private were restricted to the class/struct, it would add
anything more for encapsulation in D.
I meant to say, it "wouldn't add more".
Well, to quote Stroustrup (from that paper I cited):
"A language is said to support a style of programming if it
provides facilities that makes it convenient (reasonably easy,
safe, and efficient) to use that style. A language
does not support a technique if it takes exceptional effort or
skill to write such programs; it merely enables the technique to
be used."
If the only way to protect hidden data within a user-defined type
(lets call it a class.. or whatever you want) from other code
within the module is to put that type in it's own module, I would
argue that D 'enables' data hiding, but does not 'support' it. Of
course, I am referring to the context of a module, and any code
within that module.
The benefit of having the ability to 'not have to' put a
user-defined type in a module by itself, simply to enforce data
hiding (from other code in a module), seems pretty obvious to me.
For example, you could put tightly coupled classes in the same
module, and each class would not be able to access the hidden
parts of each other (except through an explicit declaration).
You'd be able to put unit-tests in the same module, and not have
those unit-tests accessing hidden data of your type. Etc...etc.
So the benefit is clear.
The downside? I (as yet) have never heard a convincing argument
for why D should never provide such an option to the programmer,
but should instead, continue to force programmers in to the
1-type-per-module design (which is an entirely unreasonable
contraint for a language to enforce on a programmer).
btw. This is not about beating a horse. I think the point was
raised in some comment, and various people (the usual ones,
including yourself) have decided to weigh in. That is what
results in the converstaion being had ;-)
