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

unprotected-entity unprotected-entity at gmail.com
Tue Oct 30 06:49:38 UTC 2018


On Monday, 29 October 2018 at 15:50:56 UTC, Jonathan M Davis 
wrote:
>
> If anything, many of us have been convinced of the opposite by 
> actually using D. The way that D treats private is pratical and 
> useful, and adding a way to further restrict access to member 
> variables of classes would just be a further complication to 
> the language with little to no pratical benefit.
>

Why doesn't D treat const, within a module, the same way it 
treats private?

I'm mean, either we're all friends, or we're not - which is it?

-------------
class Plane
{
     // private const int MAX_SPEED = 1000;
     //
     // bummer, my friends below can't change MAX_SPEED - it's 
const.
     // let's think of a way to help our friends...
     // I know, let's remove const
     // After all, we're all friends here.
     // nothing outside the module can touch MAX_SPEED anyway..
     // ..it's private afterall.
     private int MAX_SPEED = 1000;
}

void main()
{
     import std.stdio;

     Plane p = new Plane();
     p.MAX_SPEED = -1;
     // no..you shouldn't have done that.
     // const would have saved the day.
     // (in the same way, a properly protected 'private' could 
also save the day.

     writeln(p.MAX_SPEED); // you may never see this, as the plane 
is now crashing.
};

------------------


More information about the Digitalmars-d mailing list