Adding a new design constraint to D
Max Samukha
maxsamukha at gmail.com
Tue Jun 14 13:35:21 UTC 2022
On Tuesday, 14 June 2022 at 12:57:57 UTC, bauss wrote:
> Sure Bar wasn't in the same module, but Foo is and Bar inherits
> from Foo, thus Bar is Foo and Foo has access to _c in Foo's
> module and thus Bar should have access to Foo's private members
> in Foo's module, because Bar is Foo.
Despite the fact you can access Foo._c, you can't access it
through a different path. This is how D's scopes work, and it
makes sense. Consider:
```d
module a;
import b;
int x;
void foo()
{
b.x = 1; // no access to x through b.x, even though the
variable is visible in a.
}
```
```d
module b;
import a;
private alias x = a.x;
```
File systems work in the same way - you can't access a node via a
path going through inaccessible nodes even if the target node is
accessible from the current node via other paths.
That is, the module-level 'private' is still bad design, but it
works consistently.
More information about the Digitalmars-d
mailing list