Adding a new design constraint to D
The Zealot
zod at zod.zod
Tue Jun 14 10:21:34 UTC 2022
"but the example, is the kind of code I, and many like me, will
come to D and write, expecting that private means private to the
scope of the class."
That is a _you_ problem though. D ist different to other
languages, you cannot except it to have all the features, or for
features to behave the same way as other languages.
Now you can solve the 'problem' of not having _class private_ two
ways already.
a) put the class in it's own module.
b) put the class decleration inside a function and use an
interface declared at module scope.
In addition, _class private_ doesn't even solve the encapsulation
'problem' in the first place.
All member functions could still access all private class
members. Consider the following:
```
class Foo {
class_private int _a;
void setA(int v) { _a = v < 42 ? v : 42; }
void oh_no() { _a = 666; /*fail!!*/ }
}
```
IMHO, _class private_ doesn't add any _value_ whatsoever, and it
complicates metaprogramming.
More information about the Digitalmars-d
mailing list