`restricted` member variables

[forkit]

On Thursday, 23 June 2022 at 04:34:03 UTC, Mike Parker wrote:
> On Thursday, 23 June 2022 at 03:55:00 UTC, forkit wrote:
>
>>
>> Or is this all new to D users?
>
> I was a Java programmer before I was a D programmer. I 
> understand all of the OOP principles you've been bringing up in 
> this discussion, as I'm sure everyone else does.
>
> What I'm arguing is that those principles still hold in D. The 
> difference between D and Java (or similar) is that in D, the 
> boundary is at the module level, not the class level. 
> Everything in the module is part of the private API. We've just 
> expanded the definition of private API from "inside the class" 
> to inside the module. Your types are still as strong, still as 
> encapsulated, via the public API (outside of the module).
>

Well, I'm not sure strong is the right word here.

I think you mean, strongly enforced by something other than the 
type.

That is not the same as a strong type.

>
> Arguments that encapsulation is broken in D because of 
> private-to-the-module are purely ideological without a concrete 
> example of a problem a new protection attribute would prevent. 
> Yes, it's true that the class boundary is violated in the 
> module. But because the module is part of the private API, that 
> doesn't matter one bit.

so, just to do simulate a strong type in D, I have to take this 
tiny little base class and put it in its own module?

Woohoo! It's 2022, and i can simulate a strong type in D.

So the problem here, since so many don't get it, is that I can 
only simulate a strong type in D, by putting that type in its own 
module.

That IS the problem. That is not the basis on which a language 
can claim to support OOP using classes!

module test;
@safe:

class Base
{
   private:
     int x = 100;

   public:
     int getX(){ return this.x;}
}

class Derived : Base
{
}

unittest
{
     import std;

     Derived d = new Derived();

     writeln(d.x); // oops. mistake.
                   // can't rely on the compiler here,
                   // its hasn't a clue what's going on.

     writeln(d.getX()); // using the public interface is cool.
}