What is the difference between the different overriding methods in Scala?

前端 未结 1 916
萌比男神i
萌比男神i 2021-02-19 22:22

Scala lets you override a method in two legal ways:

Given super class:

class A {
  def a = \"A\"
}

We can override the method \"a\" by:

1条回答
  •  星月不相逢
    2021-02-19 22:57

    This hasn't always been the case (from the change log of the language specification):

    Scala version 2.0 also relaxes the rules of overriding with respect to empty parameter lists. The revised definition of matching members (§5.1.3) makes it now possible to override a method with an explicit, but empty parameter list () with a parameterless method, and vice versa.

    You are correct that this seems like an odd design decision, given that there are observable differences between parameterless methods and ones with empty parameter lists. For example, suppose you have the following:

    class A { def a = "A" }
    class B extends A { override def a = "B" }
    class C extends A { override def a() = "C" }
    

    Now we can write the following, as expected:

    scala> (new B).a
    res0: java.lang.String = B
    
    scala> (new C).a
    res1: java.lang.String = C
    

    And this:

    scala> (new C).a()
    res2: java.lang.String = C
    

    But not this:

    scala> (new B).a()
    :10: error: not enough arguments for method apply: (index: Int)Char in class StringOps.
    Unspecified value parameter index.
                  (new B).a()
    

    So Scala does make a distinction between the two, which obviously must be reflected in the bytecode. Suppose we compile the following:

    class A { def a = "A" }
    class B extends A { override def a = "B" }
    

    And then run:

    javap -verbose B > noArgList.txt
    

    Then change the code to this:

    class A { def a = "A" }
    class B extends A { override def a() = "B" }
    

    Recompile, and run:

    javap -verbose B > emptyArgList.txt
    

    And finally check for differences:

    <   MD5 checksum 88aeebf57b645fce2b2fcd2f81acdbbd
    ---
    >   MD5 checksum 3733b3e4181b4b2f4993503d4c05770e
    32c32
    <   #18 = Utf8               }1A!
                                     \t\t!ICaT-9uszaE\r)\"a\tI!!\"1Q!Dg
    jiz\"a\tAQ!BY\t!Y                                                  G.Y11bU2bY|%M[3di\")C%1A(
                     /A$H3)!dGYtwMCQM^1\nyI\"AB*ue&tw\r
    ---
    >   #18 = Utf8               }1A!
                                     \t\t!ICaT-9uszaE\r)\"a\tI!!\"1Q!Dg
    jiz\"a\tAQ!BY\t!                                                   G.Y11bU2bY|%M[3di\")C%1A(
                    /A$H3)!dGYtwMCQM^1\nyI\"AB*ue&tw\r
    

    So there is a difference—the two versions have different values for the ScalaSignature annotation.

    As to why the change was made in Scala 2.0: the specification notes that it allows this:

    class C {
        override def toString: String = ...
    }
    

    My guess is that the language designers just didn't see a reason to require users to remember which approach the overridden methods used in cases like this.

    0 讨论(0)
提交回复
热议问题