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

Fix #3339: Disallow accesses to private package members from nested pkgs #3735

Merged
merged 2 commits into from
Jan 4, 2018

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jan 2, 2018

Change of the accessibility rules: Disallow accesses to private package members from nested packages.

Such accesses were causing an access error at runtime before.

…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.
Copy link
Member

@smarter smarter left a 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.

@@ -733,7 +730,9 @@ object SymDenotations {
( !(this is Local)
|| (owner is ImplClass) // allow private local accesses to impl class members
|| isCorrectThisType(pre)
)
) &&
Copy link
Member

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?

Copy link
Contributor Author

@odersky odersky Jan 4, 2018

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.

@smarter smarter merged commit 9f4166f into scala:master Jan 4, 2018
@allanrenucci allanrenucci deleted the fix-#3339-1 branch January 4, 2018 14:31
odersky added a commit to dotty-staging/dotty that referenced this pull request Jan 25, 2019
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.
odersky added a commit to dotty-staging/dotty that referenced this pull request Feb 1, 2019
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants