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

Can we please reach some kind of decision on access #6794

Open
scabug opened this issue Dec 10, 2012 · 11 comments
Open

Can we please reach some kind of decision on access #6794

scabug opened this issue Dec 10, 2012 · 11 comments

Comments

@scabug
Copy link

scabug commented Dec 10, 2012

I've tried for years to obtain some clarity here. It is a large tax on users and compiler developers alike that even if people knew and understood what is supposed to work and how it's supposed to work with respect to the 16 permutations of qualified/object private/protected type/value visibility/access - which they don't, myself included - that knowledge would be of limited use because there are so many bugs.

The bugs persist in large part because I lack sufficient information to fix them. It would be wonderful if we could make some forward progress on this somehow. This is a small sample of the set of behaviors which are hard to explain or defend (although I admit to the possibility that all of this is "as specified" since as I said, I am incapable of deriving the intended behavior from the specification.)

trait FB[T <: FB[T]] { }

package foo {
  class Bippy {
    private[Bippy] class FB1 extends FB[FB1]
    private[foo] class FB2 extends FB[FB2]
    protected[this] class FB3 extends FB[FB3]
    protected class FB4 extends FB[FB4]

    def f1 = new FB1
    def f2 = new FB2
    def f3 = new FB3
    def f4 = new FB4
  }
}

/****

scala> val x = new foo.Bippy
x: foo.Bippy = foo.Bippy@62b6772

scala> x.f1
res0: x.FB1 = foo.Bippy$FB1@4bfd366a

scala> x.f2
res1: x.FB2 = foo.Bippy$FB2@16fc39cd

scala> x.f3
res2: x.FB3 = foo.Bippy$FB3@d72f8f7

scala> x.f4
res3: x.FB4 = foo.Bippy$FB4@104a73cb

scala> var y: x.FB1 = _
<console>:8: error: class FB1 in class Bippy cannot be accessed in foo.Bippy
       var y: x.FB1 = _
                ^

scala> var y: x.FB2 = _
<console>:8: error: class FB2 in class Bippy cannot be accessed in foo.Bippy
       var y: x.FB2 = _
                ^

scala> var y: x.FB3 = _
<console>:8: error: type FB3 is not a member of foo.Bippy
       var y: x.FB3 = _
                ^

scala> var y: x.FB4 = _
<console>:8: error: class FB4 in class Bippy cannot be accessed in foo.Bippy
 Access to protected class FB4 not permitted because
 enclosing object $iw is not a subclass of
 class Bippy in package foo where target is defined
       var y: x.FB4 = _
                ^

After all that, god forbid we let 'private class FB5' escape...

scala> private class FB5 ; def f5 = new FB5
<console>:7: error: private class FB5 escapes its defining scope as part of type FB5
       private class FB5 ; def f5 = new FB5
                               ^

***/
@scabug
Copy link
Author

scabug commented Dec 10, 2012

@retronym said:
That's some thorough linkin'!

@scabug
Copy link
Author

scabug commented Dec 10, 2012

@paulp said:
It's a lot less than I could have done. I mostly left out some strongly related subjects like name mangling (much of the complexity of which arises from the access scheme), super/trait/protected accessors, etc. But this much should offer a taste.

@scabug
Copy link
Author

scabug commented Dec 29, 2013

Mike Slinn (mslinn) said:
Will this issue be resolved for 2.11 release?

@scabug
Copy link
Author

scabug commented Dec 29, 2013

@retronym said:
This is a meta-bug, it isn't going to be solved in one hit. The change in 'fix-by' version was part of a bulk change.

@scabug
Copy link
Author

scabug commented Dec 29, 2013

Mike Slinn (mslinn) said:
Jason, not sure what the conclusion is. The bug is currently unassigned. Will there be any improvement in the area described by this bug report for 2.11? ... Thanks!

@scabug
Copy link
Author

scabug commented Dec 30, 2013

@retronym said:
Mike: we are wrapping up 2.11 and don't plan to make changes related to access at this late stage in the cycle.

@scabug
Copy link
Author

scabug commented Dec 30, 2013

Mike Slinn (mslinn) said:
That is unfortunate. I am ready to rerecord a lecture for http://scalacourses.com which discusses this visibility. Earlier versions of the lecture referenced 2.11M5 as being the point at which access visibility would achieve greater clarity, then 2.11M7. Instead, I will have to continue to say that this remains poorly defined and recommend that the undefined modifiers should be avoided.

Might it still be possible to enhance the documentation to state which modifiers that actually work as per spec, and inform the reader that the other possibilities are undefined? Here are the 8 possibilities I am referring to: protected, protected[packageName], protected[className], protected[this], private, private[packageName], private[className] and private[this].

@som-snytt
Copy link

#4559

@Jasper-M
Copy link
Member

Jasper-M commented Nov 9, 2020

Not 100% sure whether we have this one already:

scala> object outer {
     |   object foo {
     |     trait A { private[foo] def a = println("a") }
     |   }
     |   object bar {
     |     trait B extends foo.A { override def a = println("b") }
     |   }
     | }
object outer

Edit: Hard to believe but it just wasn't linked #11339

@som-snytt
Copy link

If someone adds a question mark to the ticket title, then it can be closed by answering, "No."

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

5 participants