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