Question about overloaded methods

[Thomas Pawlitzki-4]

Hello,

I have a question about overloading methods.
Look at the following example:
object ScalaTest extends Application {
 def test(a: A) {
    Console.println("=== Test ===")
    a.foo(new ParamA)
    a.foo(new ParamB)
  }
  val a = new A(){}
  test(a)
  val b = new B()
  test(b)
}
class ParamA
class ParamB extends ParamA
trait A {
  def foo(paramA: ParamA) { Console.println("A.foo(ParamA)")}
}
class B extends A {
  def foo(paramB : ParamB) { Console.println("B.foo(ParamB)")}
}

Whenn executing the example I expected the output
=== Test ===
A.foo(ParamA)
A.foo(ParamA)
=== Test ===
A.foo(ParamA)
B.foo(ParamB)

But the last line is also an
A.foo(ParamA)

It seems as if the resolving of the overloaded methods does not work
like the resolving of overridden methods (late binding).
I re-implemented the example in Java and had the same result. Also
there the resolving of overloaded methods seems not to be done during
runtime.

Is there an explanation?

Thanks and cheers,
Thomas

[Paul Phillips-3]

On Thu, Oct 29, 2009 at 10:43:16PM +0100, Thomas Pawlitzki wrote:
> It seems as if the resolving of the overloaded methods does not work
> like the resolving of overridden methods (late binding). I
> re-implemented the example in Java and had the same result. Also there
> the resolving of overloaded methods seems not to be done during
> runtime.

Right.

> Is there an explanation?

I would say you just explained it perfectly.  Do you want an explanation
of something other than what you explained? Motivation? Scala is the way
it is to be like java.  Who knows who java was trying to be like.  The
cooler language down the block, maybe.

--
Paul Phillips      | These are the climbs that apply men's soles.
Imperfectionist    |
Empiricist         |
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------

[christopher marshall-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

> It seems as if the resolving of the overloaded methods does not work
> like the resolving of overridden methods (late binding).
> I re-implemented the example in Java and had the same result. Also
> there the resolving of overloaded methods seems not to be done during
> runtime.
>
> Is there an explanation?

The method being called is determined at compile-time based on the type of the parameters used in the call. The actual parameter types at runtime are of course not known at compile-time! Think of "the method" in the above sentience as being "the method name plus parameters".

---

Download Messenger onto your mobile for free. Learn more.

[Daniel Sobral]

You are confusing overloading with polymorphism. From wikipedia:

Method overloading is a feature found in various programming languages such as Ada, C#, C++, D and Java that allows the creation of several methods with the same name which differ from each other in terms of the type of the input and the type of the output of the function.

Subtype polymorphism, almost universally called just polymorphism in the context of object-oriented programming, is the ability of one type, A, to appear as and be used like another type, B. 

...

The primary usage of polymorphism in industry (object-oriented programming theory) is the ability of objects belonging to different types to respond to method, field, or property calls of the same name, each one according to an appropriate type-specific behavior. 

Clearly, you are overloading the method "foo". You have two methods: one which receives a ParamA, and one which receives a ParamB.

What you are _not_ doing is method polymorphism. First, it would require you to use the "override", the absence of which would cause a compile-time error. Second, it would require for you to declare the method "foo" in B with the same parameters as declared in A.

If you do that, you'll see that, indeed, there is late binding of the method. It would happen if you were to declare B like this:

trait B extends A {

 override def foo(paramA: ParamA) { Console.println("B.foo(ParamA)")}

}

On Thu, Oct 29, 2009 at 7:43 PM, Thomas Pawlitzki <thomas.pawlitzki@...> wrote:

Hello,

I have a question about overloading methods.
Look at the following example:
object ScalaTest extends Application {
 def test(a: A) {
   Console.println("=== Test ===")
   a.foo(new ParamA)
   a.foo(new ParamB)
 }
 val a = new A(){}
 test(a)
 val b = new B()
 test(b)
}
class ParamA
class ParamB extends ParamA
trait A {
 def foo(paramA: ParamA) { Console.println("A.foo(ParamA)")}
}
class B extends A {
 def foo(paramB : ParamB) { Console.println("B.foo(ParamB)")}
}

Whenn executing the example I expected the output
=== Test ===
A.foo(ParamA)
A.foo(ParamA)
=== Test ===
A.foo(ParamA)
B.foo(ParamB)

But the last line is also an
A.foo(ParamA)

It seems as if the resolving of the overloaded methods does not work
like the resolving of overridden methods (late binding).
I re-implemented the example in Java and had the same result. Also
there the resolving of overloaded methods seems not to be done during
runtime.

Is there an explanation?

Thanks and cheers,
Thomas

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Ricky Clarkson]

These are single-dispatch languages; they dispatch methods based only
on the class of 'this'.  Compare multiple dispatch, such as Common
Lisp, where a method can be chosen on the class of any number of the
arguments.  Also compare Haskell, which has multiple dispatch, but it
is decided statically based on type, rather than class (which is handy
as Haskell has no classes).

2009/10/29 Thomas Pawlitzki <thomas.pawlitzki@...>:

> Hello,
>
> I have a question about overloading methods.
> Look at the following example:
> object ScalaTest extends Application {
>  def test(a: A) {
>    Console.println("=== Test ===")
>    a.foo(new ParamA)
>    a.foo(new ParamB)
>  }
>  val a = new A(){}
>  test(a)
>  val b = new B()
>  test(b)
> }
> class ParamA
> class ParamB extends ParamA
> trait A {
>  def foo(paramA: ParamA) { Console.println("A.foo(ParamA)")}
> }
> class B extends A {
>  def foo(paramB : ParamB) { Console.println("B.foo(ParamB)")}
> }
>
> Whenn executing the example I expected the output
> === Test ===
> A.foo(ParamA)
> A.foo(ParamA)
> === Test ===
> A.foo(ParamA)
> B.foo(ParamB)
>
> But the last line is also an
> A.foo(ParamA)
>
> It seems as if the resolving of the overloaded methods does not work
> like the resolving of overridden methods (late binding).
> I re-implemented the example in Java and had the same result. Also
> there the resolving of overloaded methods seems not to be done during
> runtime.
>
> Is there an explanation?
>
> Thanks and cheers,
> Thomas
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Thomas Pawlitzki-4]

Hey Paul and all others having replied,


On Thu, Oct 29, 2009 at 10:56 PM, Paul Phillips <paulp@...> wrote:
> On Thu, Oct 29, 2009 at 10:43:16PM +0100, Thomas Pawlitzki wrote:
>> [...]
>
> Right.

so it seems that I still have to determine the most specific method
reflectively. It seems for me that I could simplify my code a lot in
the case the compiler/runtime can do this determination for me.

Cheers,
Thomas

[Jesper Nordenberg]

Thomas Pawlitzki wrote:
> so it seems that I still have to determine the most specific method
> reflectively.

Now, that's a bad idea.

 > It seems for me that I could simplify my code a lot in
> the case the compiler/runtime can do this determination for me.

It can using pattern matching or dynamic dispatch. Seems to me you want
to extend an existing type hierarchy with new methods. There are two
preferred approaches for this in Scala, pattern matching:

sealed trait Base
class A extends Base
class B extends Base

def someFn(b : Base) = b match {
   case a : A => <do something for A>
   case b : B => <do something for B>
}

Or you can use variants of the visitor pattern, see:

http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.pdf
http://www.comlab.ox.ac.uk//files/2187/ModularVisitor.pdf

/Jesper Nordenberg

[Thomas Pawlitzki-4]

Hello Jesper,

> It can using pattern matching or dynamic dispatch. Seems to me you want to
> extend an existing type hierarchy with new methods. There are two preferred
> approaches for this in Scala, pattern matching:
> [...]

No, pattern matching is no option for me as I do not know all the
types. Actual I do know only the abstract base types and all concrete
types or not in my focus.

> Or you can use variants of the visitor pattern, see:
>
> http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.pdf
> http://www.comlab.ox.ac.uk//files/2187/ModularVisitor.pdf

I will have a look at this. Thanks for the links

Cheers,
Thomas

[Andrew Gaydenko]

On Friday 30 October 2009 11:47:49 Jesper Nordenberg wrote:
> Or you can use variants of the visitor pattern, see:
>
> http://www.scala-lang.org/docu/files/IC_TECH_REPORT_200433.pdf

Jesper,

Have you tried to translate a code from this article to current Scala?
Extensions like this one

class Num(v: Int) extends super[ShowPlusNeg].Num(v) with
super[DblePlusNeg].Num(v) with Exp

don't work, of course.