The standard output is three lines:This is program output, excluding any interactive interpreter's display of returned values. The calls
A
2.3
Ba.m(1) and b.m(5.6) compute squares without printing. In A, the concrete m(Int) wins over the generic method at argument 1; the string and 2.3 use m[T] and print their arguments.For
b: B[Any], the class type parameter has already become Any, so the two alternatives are m(Any) and m(Double), rather than a method with its own freely inferred type parameter. The Double alternative is more specific. It accepts 4 by numeric widening, so b.m(4) computes 16.0 without printing; b.m("B") prints B; b.m(5.6) computes a square without printing. These are applications of the Scala 2.11 method overloading rules, with the arithmetic return values discarded in statement position.[ref]https://www.scala-lang.org/files/archive/spec/2.11/06-expressions.html#overloading-resolution. Scala 2.11 Language Specification, §6.26.3, overload applicability and specificity
Two mechanisms are subtype polymorphism and parametric polymorphism.
With subtype polymorphism, a trait or abstract class declares an operation and concrete subclasses implement or override it. A
Player reference holding a House object invokes House.play through dynamic dispatch. The client is written against the common contract.With parametric polymorphism, a software class or generic method has a type parameter, such as
List[T] or def identity[T](x: T): T = x. The same definition works for many supplied type arguments, with static relationships between input and output types. Method overloading is another mechanism, usually called ad hoc polymorphism: alternatives share a name but are selected from their parameter signatures at compile time.