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

[Danni Coy]

On Sun, Oct 28, 2018 at 9:30 PM unprotected-entity via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:
> >
> > You can make the same mistake inside the class:
> >
> > class Foo {
> >    private int x;
> >    void increment() {...}
> >    ...
> >    void doSomethingInternal() { x++; }
> > }
> >
> > How is making that mistake outside of that final curly brace
> > any different or any worse? It's all in the same file.
>
> Except, that (I assume) a module in D is meant to be more than
> just a single class.
>
> If that's not the case, then my argument is irrelevant.
>
> If it is the case, then you presumably would have a great deal
> more code in your module, than you would in a single class.
> Hence, greater likelihood of mistakingly
> accessing a private member of some class defined within the
> module, somewhere.
>
> In any case, it does undermine the principle of encapsulation
> (assuming you agree that a class deserves to be a unit of
> encapsulation).
>
> In, it's nothing more than a convenient hack, really.
>
> There is not a third option here.
>
> The advantage of the Way D does things is that you don't have to put your
data into a class and instantiate it in order to have encapsulation.
In C++ for instance often data is put into a class just to have
encapsulation, this has a cost in resources as well the complexity of
program.
In D any data that there only needs to be one copy of and lasts the
lifetime of the program belongs in a module rather than a class.
In practice this tends to mean less classes, and less of the work done
inside classes.
D source code can feel inside out compared to C++ source code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20181029/4ce971e4/attachment.html>