Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

private should mean private #41

Open
marler8997 opened this issue Dec 11, 2018 · 3 comments
Open

private should mean private #41

marler8997 opened this issue Dec 11, 2018 · 3 comments

Comments

@marler8997
Copy link
Collaborator

marler8997 commented Dec 11, 2018

In my opinion, private should mean private to the class/struct, not to the module. I think module ownership is a fine idea, but should be have it's own visibility.

struct Foo
{
    private int x;
    package int y;
    module int z; // ???
}

Foo foo;
foo.x; // error, x is not visible
foo.y; // ok
foo.z; // ok
@wilzbach
Copy link
Collaborator

I never considered this a big issue. On the contrary, I quite like that for testing you can introspect into the class if you want to.
(though I don't have a strong feeling about this)

@marler8997
Copy link
Collaborator Author

marler8997 commented Dec 11, 2018

Yeah, white box testing is good and this problem of accessing private fields is a common one in any language. One idea is to have the language grant visibility to all private fields if it's inside a unittest block or version(unittest).

@aliak00
Copy link

aliak00 commented Jul 1, 2019

Or have a fileprivate scope or public/protected/private/package/module. Or package(this) to mean module. Or private(this) to mean "real" private and don't change the current private.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants