Skip to content
Commits on Sep 14, 2012
  1. @paulp

    Eliminate breaking relative names in source.

    paulp committed
    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
  1. @paulp

    Dropped about 1.5 Mb off scala-library.jar.

    paulp committed
    This commit and the two subsequent commits were contributed by:
    
      Todd Vierling <tv@duh.org>.
    
    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
  1. @paulp
Something went wrong with that request. Please try again.