-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix #3339: Disallow accesses to private package members from nested pkgs #3735
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
Conversation
…ted pkgs Change of the accessibility rules: Disallow accesses to private package members from nested packages. Such accesses were causing an access error at runtime before.
smarter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise LGTM but a test case is missing.
| || (owner is ImplClass) // allow private local accesses to impl class members | ||
| || isCorrectThisType(pre) | ||
| ) | ||
| ) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This long chain of conditions is getting really hard to read, factor it out into a few vals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried but it does not seem to help. The key is treating !A || B as an implication, then things get clearer. I was wondering whether we should add an inline helper method implies on Boolean to do this. But it's quite a lot of effort.
Test case is i3339. In
```
package outer {
private class A() {
override def toString = "A"
}
package inner {
object Test {
def main(args: Array[String]): Unit = {
println(new A()) // allow access?
}
}
}
}
```
should the access to private class `A` from a nested package be allowed?
The usual rules for Scala say yes, since the access is from a nested scope.
We changed this to in scala#3735 to "no", since we wanted to emulate Java's default
package-private visibility. But this is unsystematic for two reasons:
- it breaks the universal meaning of `private` in Scala
- it uses a different name (i.e. private) for what is not named
in Java at all, and is named `internal` in Kotlin.
- it does not generalize to members of classes which could
also profit from a Java-package-private visibility specifier.
I believe it is better to leave `private` as it is, and, if we want to
emulate `internal` (which might be a good idea), introduce a new modifier
for it.
Test case is i3339. In
```
package outer {
private class A() {
override def toString = "A"
}
package inner {
object Test {
def main(args: Array[String]): Unit = {
println(new A()) // allow access?
}
}
}
}
```
should the access to private class `A` from a nested package be allowed?
The usual rules for Scala say yes, since the access is from a nested scope.
We changed this to in scala#3735 to "no", since we wanted to emulate Java's default
package-private visibility. But this is unsystematic for two reasons:
- it breaks the universal meaning of `private` in Scala
- it uses a different name (i.e. private) for what is not named
in Java at all, and is named `internal` in Kotlin.
- it does not generalize to members of classes which could
also profit from a Java-package-private visibility specifier.
I believe it is better to leave `private` as it is, and, if we want to
emulate `internal` (which might be a good idea), introduce a new modifier
for it.
Change of the accessibility rules: Disallow accesses to private package members from nested packages.
Such accesses were causing an access error at runtime before.