Martin edited on 2004-07-01 15:56:17.0
|
If you write what you put in the comment, you do get an error!
|
Martin edited on 2004-07-01 15:56:53.0
|
|
Burak edited on 2004-07-01 17:27:08.0
|
yes, but allowing this can circumvent every private/public by escaping private stuff.
"private" should mean that neither class Foo, neither any of its members is seen.
|
Burak edited on 2004-07-01 17:52:30.0
|
Here is an example:
package scalaInner1;
class C {
private var x = 3;
private class Foo {
def bar = { x = 4; }
}
def get:Foo = new Foo();
}
object Test {
def main(args:Array[String]) = {
val c = new C().get;
c.bar;
}
}
|
Burak edited on 2004-07-01 17:56:30.0
|
Maybe type inference could give c the least public upper bound (in this case object) ? I fear not doing anything about this undermines the use of public/private...
|
Nikolay edited on 2005-03-02 15:15:29.0
|
I reopened this bug as agreed at the last Scala meeting. The example compiles (although it shouldn't) and runs OK on JVM and .NET. The latter is a side effect of the last changes in the .NET backend. Since inner classes end up in the interface of a Scala class they are not accesible from the implementation class if defined as private; not even Foo's constructor. I had to give private inner classes assembly visibility to work around this restriction. I think the same should apply for protected classes too. Currently, protected inner classes are translated as public (mixins issue maybe) so the problem doesn't show up there. However, this breaks encapsulation. I think the rule should be sth like "The type of a member (including parameter and return types of defs) should not be less accessible than the member itself."
|
Nikolay edited on 2005-03-02 15:16:02.0
|
|
Martin edited on 2006-03-30 18:46:30.0
|
You now get an error:
files/new/bug343.scala:5 error: private class Foo escapes its defining scope as part of type C.this.Foo
def get:Foo = new Foo();
^
one error found
|