Scala Programming Language
  1. Scala Programming Language
  2. SI-4846

Artifacts from AnyVal getClass appear in signatures

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Misc Compiler
    • Labels:
      None
    • Environment:

      Scala 2.10.0.r25323-b20110719020429

      Description

      In 2.9.0.1:

      scala> List(1) ++ List('a')
      res0: List[AnyVal] = List(1, a)
      

      In 2.9.1RC1/2.10-trunk:

      scala> List(1) ++ List('a')
      res0: List[AnyVal{def getClass(): java.lang.Class[_ >: Int with Char <: AnyVal]}] = List(1, a)
      

      I'm not sure if this is a bug or an enhancement.

      Imho the type signature is exposing some implementation detail of getCLass for AnyVals (probably related to SI-864) and shouldn't appear anywhere.

      I really don't want to explain that type signature to a beginner ...

        Issue Links

          Activity

          Hide
          Paul Phillips added a comment -

          There has been worse stuff than this for a long time and we've survived this long.

          Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26).

          scala> List(1L: java.lang.Long) ++ List(1: java.lang.Integer)
          res0: List[java.lang.Number with java.lang.Comparable[_ >: java.lang.Long with java.lang.Integer <: java.lang.Number with java.lang.Comparable[_ >: java.lang.Long with java.lang.Integer <: java.lang.Number with java.lang.Comparable[_ >: java.lang.Long with java.lang.Integer <: java.lang.Number]]]] = List(1, 1)

          Show
          Paul Phillips added a comment - There has been worse stuff than this for a long time and we've survived this long. Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_26). scala> List(1L: java.lang.Long) ++ List(1: java.lang.Integer) res0: List[java.lang.Number with java.lang.Comparable[_ >: java.lang.Long with java.lang.Integer <: java.lang.Number with java.lang.Comparable[_ >: java.lang.Long with java.lang.Integer <: java.lang.Number with java.lang.Comparable [_ >: java.lang.Long with java.lang.Integer <: java.lang.Number] ]]] = List(1, 1)
          Hide
          Seth Tisue added a comment -

          Martin writes: "Since refinements are legal Scala types they may appear as lubs. That fact is used in a lot of Scala code. One way out of this particular pickle would be to teach the typechecker that the glb of Char and Int is Nothing, and likewise for the other value types. I think that would fix the problem." from https://groups.google.com/d/msg/scala-language/mThYtcdajfc/9b3wJa2VOwAJ

          So, reopening the ticket but reclassifying it as an enhancement. Martin's suggestion wouldn't help the java.lang.Long/Integer case Paul noticed, but oh well.

          Show
          Seth Tisue added a comment - Martin writes: "Since refinements are legal Scala types they may appear as lubs. That fact is used in a lot of Scala code. One way out of this particular pickle would be to teach the typechecker that the glb of Char and Int is Nothing, and likewise for the other value types. I think that would fix the problem." from https://groups.google.com/d/msg/scala-language/mThYtcdajfc/9b3wJa2VOwAJ So, reopening the ticket but reclassifying it as an enhancement. Martin's suggestion wouldn't help the java.lang.Long/Integer case Paul noticed, but oh well.
          Hide
          Seth Tisue added a comment -

          Martin withdraws that fix and suggests three possible alternatives at https://groups.google.com/d/msg/scala-language/mThYtcdajfc/D_LX44WtmeoJ

          Show
          Seth Tisue added a comment - Martin withdraws that fix and suggests three possible alternatives at https://groups.google.com/d/msg/scala-language/mThYtcdajfc/D_LX44WtmeoJ
          Hide
          Commit Message Bot added a comment -

          (extempore in r26001) Sin some more.

          "Fiddle with lubs and glbs by never considering getClass as a member in
          a refinement generated from them. In a sense we have justification for
          this by saying we already treated getClass in an ad-hoc way, so we might
          as well go all the way." – m. odersky

          Closes SI-4846.

          Show
          Commit Message Bot added a comment - (extempore in r26001 ) Sin some more. "Fiddle with lubs and glbs by never considering getClass as a member in a refinement generated from them. In a sense we have justification for this by saying we already treated getClass in an ad-hoc way, so we might as well go all the way." – m. odersky Closes SI-4846 .
          Hide
          Seth Tisue added a comment -

          hooray!

          Show
          Seth Tisue added a comment - hooray!

            People

            • Assignee:
              Paul Phillips
              Reporter:
              Simon Ochsenreither
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development