On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote:
I think it's a great feature and I use it frequently. It's
allows more flexibility in class design. Without it, we'd need
another protection attribute to enable the concept of "private
to the module".
what about a new access attribute (and no, I haven't though
this through much):
owned string _FirstName;
(now the class 'owns' this.
It is neither readable nor writeable outside the boundary of
This retains the existing flexibilty offered by module level
encapsulation, while restoring class level
So, what's wrong with this?
public int pub;
private int priv;
auto c = new Blah();
c.priv = 42; // compile error
You can still code like Java, one file per class (module) and
keep those private members protection across modules classes.
What's different with D is that the scope is the module not the
class (package), and this is good. This is a trade-of, usually
one codes related components in a module, thus frequently needs
access to those components inside the module. You can have class,
struct, functions, enums, static variables and templates in the
same module, and pragmatically you will need to access private
data on them. You still have the private to signal the intent,
just that the philosophy is different when looking at the basic