Why do private member variables behaved like protected in the same module when creating deriving class?
Mike Parker
aldacron at gmail.com
Sun Oct 28 11:32:07 UTC 2018
On Sunday, 28 October 2018 at 11:27:01 UTC, unprotected-entity
wrote:
> On Sunday, 28 October 2018 at 05:28:31 UTC, Mike Parker wrote:
>> 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.
Modules can contain as many classes as you like or none at all.
That doesn't change anything. It's still all in the same file.
>
> 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.
And full access to the file to change it if you do make that
mistake. No encapsulation broken.
>
> In any case, it does undermine the principle of encapsulation
> (assuming you agree that a class deserves to be a unit of
> encapsulation).
In D, the module is the unit of encapsulation, not the class.
More information about the Digitalmars-d
mailing list