Why do private member variables behaved like protected in the same module when creating deriving class?

unprotected-entity unprotected-entity at gmail.com
Mon Oct 29 05:13:22 UTC 2018


On Sunday, 28 October 2018 at 11:32:07 UTC, Mike Parker wrote:
>
> In D, the module is the unit of encapsulation, not the class.

That is not entirely correct.

---
module test;
import std.stdio;
void test() { int a; }
void main() { writeln(a); } // Error: undefined identifier 'a'
---

The D module still considers a function to be it's own unit of 
encapsulation.

Classes no longer have that status in D.

Now, for the small number of D users, it seems a relative 
non-issue. Fine.

I wonder if that would still be the case, if millions and 
millions of C++/Java/C# programmers suddenly came over to D (and 
discovered, likely by accident, or by some obscure bug in their 
code), that a class is not considered a unit of encapsulation 
anymore.

I think you would then have a much harder time convincing larger 
numbers of programmers, that D has done a good thing here (n 
terms of architecturing better software) by altering the most 
important encapsulating property of a class - private.

I'm guarantee, that you'd be getting a *lot* more DIP's that try 
to address it ;-)

I think Go and Rust have done it better, somewhat, in that they 
don't even have classes. So you are forced to rethink your design 
anyway (if you want to use those languages)

Having said that, I am yet to hear a really good argument, as for 
why everything in a module *must* be your friends. Encapsulation, 
is not about having lots of friends that can poke at your private 
parts - no matter what language it is.

But in a language that offers 'classes', but NOT as unit of 
encapsulation in its own right (within a module that is), well, I 
find that rather odd, and disconcerting (in terms of reasonable 
guarantees of your softwares correctness).

I understand that practical considerations are often more 
important, and useful, that theoretical standpoints, but even so, 
I do not see the wholesale practicality and usefulness of the 
decision made in D, in relation to this matter.

Yes, there are situations in which it might be useful, I get it. 
But surely not every situation?




More information about the Digitalmars-d mailing list