Skip to content

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.

|| (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