Adding a new design constraint to D

[Ola Fosheim Grøstad]

On Tuesday, 14 June 2022 at 13:35:21 UTC, Max Samukha wrote:
> 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.

It isn't necessarily through a different path unless you think 
that Bar is cloaking Foo, basically redoing everything that is 
Foo.

So it is a matter of philosophy: do you think that Bar is an 
extension of Foo? Or do you think that Bar is a shell around Foo?

 From a purist OO viewpoint then Bar should be only an addition to 
Foo with no ability to redefine anything Foo'ish without Foo's 
consent. (C++ does not belong in this category I think…)

I believe it is a mistake to mix up lookup with access, because 
it means you cannot give or grant access without having to 
rewrite code elsewhere. It also makes it more difficult to 
refactor (move a class from one context to another).

Not really the most pressing issue for D though.