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 that class.

This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.

So, what's wrong with this?
module foo;
class Blah
    public int pub;
    private int priv;
module bar;

import foo;

void main()
   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 compilation unit.

Reply via email to