On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
I wouldn't consider putting classes into own modules a
workaround. In my opinion it's more or less the solution.
I'll add your solution into my article - but, I'm not sure it
really addresses my problem statement.
The Problem Statement (being drafted still):
---------------------
In the D programming language, the semantics of the access-level
modifier 'private' is likely very different to what a large
number of programmers from object-oriented, and class-oriented
languages, might expect.
In D, the module (not the class) is the overarching entity, and
one that encompasses all other entities within the module.
In D, The module can contain (and typically would contain) a
variety of types - functions, structs, classes and so on.
If a module contains a class type however, and that class has a
private access modifier on it's members, then that private access
modifier becomes moot (within the module), because all the
surrounding code in that module can directly access (and even
modify) those private members.
The module implicitly morphs a 'private' access modifier, into a
'private-but-also-module-public' modifier.
The programmer has no control over this implicit conversion of
the access modifier.
This would be unfamiliar, and unexpected, to a very large number
of programmers from languages where 'private' has an established
and well-defined semantic as being the most restrictive form of
access to a class member.
Unfortunately, in the D programming language, there is simply no
way to declare a member of a class to be private, and prevent
surrounding code (within the module) from accessing it.
The D module, will implicitly change the semantics of your code.
The Implications:
----------------
..to do....
