Aladdin - Scala Bugtracking
[#812] project: specification priority: low category: bug
submitter assigned to status date submitted
Sean Martin won't fix 2006-11-10 12:21:38.0
subject import renaming not compatible with super/private/protected qualifiers
code 
package test;
import scala.{Application => Main};
class Test extends Main {
  import test.{Test => Hello}
  super[Main].executionStart;
  private[Hello] def xxx = 10;
}
what happened 
Severity and De5cr1p7-haX0Rion	Path	Resource	Location	Creation Time	Id
Main does not name a parent class of class Test	test33/src/test	Test.scala	line 5	1163146384790	198401
Hello is not an enclosing class	test33/src/test	Test.scala	line 6	1163146384790	198400
what expected I think I must have run into this before (maybe with type aliases?). Anyways import renaming must work ubiquitously and for super/private/protected qualifiers, or the feature should be considered extremely fragile.
[back to overview]
Changes of this bug report
Martin  edited on  2006-11-10 18:31:14.0
Well, let's consider it extremely fragile, then. Note that qualifier prefixes are *not* idents so import renaming does not apply to them. Such import renaming would be rather rather hard to specify, IMO.
Sean  edited on  2006-11-11 13:49:47.0
Then maybe we should get rid of renaming if it can't fully be supported? This is similar to the problem that tool-assisted refactoring cannot be supported in Scala.
Martin  edited on  2006-11-11 19:28:17.0
I don't think name qualification has anything to do with imports. Here's a thought experiment: 
class C
  class Inner {
    type C = int
    Console.println(C.this.bar)
  }
  val bar = 2
}
In this case, the C.this will correctly refer to the outer class, even though an *identifier* C would refer to the inner type (I believe Java works the same way). This shows that name qualification has nothing to do with identifier resolution! Since imports influence identifier resolution, they should have nothing to do with name qualification either.