Commits on Sep 14, 2012
These things are killing me. Constructions like package scala.foo.bar.baz import foo.Other DO NOT WORK in general. Such files are not really in the "scala" package, because it is not declared package scala package foo.bar.baz And there is a second problem: using a relative path name means compilation will fail in the presence of a directory of the same name, e.g. % mkdir reflect % scalac src/reflect/scala/reflect/internal/util/Position.scala src/reflect/scala/reflect/internal/util/Position.scala:9: error: object ClassTag is not a member of package reflect import reflect.ClassTag ^ src/reflect/scala/reflect/internal/util/Position.scala:10: error: object base is not a member of package reflect import reflect.base.Attachments ^ As a rule, do not use relative package paths unless you have explicitly imported the path to which you think you are relative. Better yet, don't use them at all. Unfortunately they mostly work because scala variously thinks everything scala.* is in the scala package and/or because you usually aren't bootstrapping and it falls through to an existing version of the class already on the classpath. Making the paths explicit is not a complete solution - in particular, we remain enormously vulnerable to any directory or package called "scala" which isn't ours - but it greatly limts the severity of the problem.
Commits on Nov 7, 2011
This commit and the two subsequent commits were contributed by: Todd Vierling <email@example.com>. I combined some commits and mangled his commit messages, but all the credit is his. This pursues the same approach to classfile reduction seen in r19989 when AbstractFunctionN was introduced, but applies it to the collections. Thanks to -Xlint it's easy to verify that the private types don't escape. Design considerations as articulated by Todd: * Don't necessarily create concrete types for _everything_. Where a subtrait only provides a few additional methods, don't bother; instead, use the supertrait's concrete class and retain the "with". For example, "extends AbstractSeq[A] with LinearSeq[A]". * Examine all classes with .class file size greater than 10k. Named classes and class names ending in $$anon$<num> are candidates for analysis. * If a return type is currently inferred where an anon subclass would be returned, make the return type explicit. Don't allow the library-private abstract classes to leak into the public namespace [and scaladoc].
Commits on Oct 19, 2010