Discussion : Can we say Overloading as polymorphism

Cracked Down

Hi all, as stated in the subject line can we say function overloading as polymorphism?? According to some oops authors overloading is compile time and overriding is runtime polymorphism!!! However, if we visit the definition of Grady Booch for Polymorphism is "One interface many implementation",which means that overloading is not a type of polymorphism! (as interface gets changed when we change the function parameter) What do you say? What is your opinion? Deep Happy coding

Nagy Vilmos

Overloading and overriding are different concepts; the later being more the polymorphism.

class EggSample
{
// miss loads

void Method()
{
// Method with nothing
}

void Method(string param)
{
// Overloading Method with a string
}

void Method(int count, string param)
{
// Overloading Method with a number and a string
}
}

That is the overloads - same method name with a different signature in a class. Overriding would be:

class HenOther : EggSample
{
// miss loads

void Method(string param)
{
// Overrides the Method with a string from EggSample
}

}

It's like an inbred hillbilly family - they all look the same but each behaves in a slightly odd way.

Panic, Chaos, Destruction. My work here is done.

Rob Philpott

Overloading is just calling different methods with the same name by different parameter signatures. I wouldn't call this polymorphism. Really not. As said, this is resolved at compile time. Overriding a virtual method however is the mainstay of polymorphism.

Regards, Rob Philpott.

Cracked Down

anybody else here who like to share his/her thought on this topic??

dojohansen

Well that's not actually an override. What you did is method hiding, and the compiler will warn you and say you should put the "new" keyword on the method declaration if the hiding was intended. Polymorphism is incredibly powerful and can greatly simplify the design of many a thing. It is, in my view, the single most important concept of OOP, even more important than encapsulation (though that is certainly important too). Virtual methods are said to be "late bound" and non-virtual methods "early bound". What this means is that when the compiler creates the CIL (formerly MSIL) code for your C# or other .net code, for non-virtual methods it will create code that invokes a specific method. Which method is called is determined by looking at the declared type of the reference to the object (or the type indicated for static methods, which obviously can never be virtual or behave polymorphically). The above is NOT polymorphic. Given this code:

EggSample obj = new HenOther();
obj.Method("param");

We are allowed to do this of course, because HenOther extends EggSample. However, the compiler will create code to invoke EggSample.Method(), not HenOther.Method(), because "obj" (my reference) has the declared type EggSample, even though it's run-time type is in fact HenOther. Virtual methods on the other hand are handled differently. The compiler will generate code to look up the method to call at run-time from what's called the type's VMT - Virtual Method Table. This means there's a small performance hit involved in invoking virtual methods, but that the method called is determined by the run-time (actual) type of the object rather than the declared type. This is extremely useful in lots of situations, because it allows us to divide and conquer in ways we never could without it. Imagine you want to create a data transformation system that can read input files, process the input and compute statistics or whatever, and transform flat files to xml and lots of stuff. You'd have a gazillion ways to do this of course, but one approach could be to build a tree structure where each node in the tree represents some operation on the data and the structure of the tree creates a breakdown of the work. You could then use polymorphy to great effect. You could use either an interface (which is of course inherently polymorphic) or a simple base class, like this:

abstract public class ProcessingNode
{
public List<processingnode> Children = new List<processingnode>();

v

Nagy Vilmos

I didn't do that right :-O I was coding 'freehand' without the use of an IDE or compiler and I was writing some java stuff last night where the above (with the correct syntax for String) would work as described. But polymorphism it is, that's the whole point of it. Different classes being able to accept the same methods and behave differently depending on their own internals. woteva.ToString(); will behave in the correct way for the class woteva - whatever it may be. But then overloading is also a form of 'lotsaforms' . :-D

Panic, Chaos, Destruction. My work here is done.

dojohansen

Indeed, you didn't do that right. Not sure what you mean by "polymorphism it is", but I hope you're not clamining that the code you posted results in polymorphic behavior. It doesn't, as you can verify for yourself using this code:

public class A
{
public void M1() { Debug.WriteLine("A.M1()"); }
virtual public void M2() { Debug.WriteLine("A.M2()"); }
}

public class B : A
{
new public void M1() { Debug.WriteLine("B.M1()"); } // Hiding - not polymorphic
virtual public void M2() { Debug.WriteLine("B.M2()"); } // Virtual - polymorphic
}

class Program
{
static public void Main(string[] args)
{
B b = new B();
A b_declared_as_a = b;

  b.M1();
  b.M2();
  b\_declared\_as\_a.M1();
  b\_declared\_as\_a.M2();

}
}

Now, we have two references to a single object instance. The non-virtual method M1() is called based on the *declared* type of the object - thus A.M1() executes when we invoke b_declared_as_a.M1() - because that reference is declared as type A. The virtual method M2() however always results in running B.M2(), because that's the run-time type of the object and the declared type is irrelevant for virtual method calls. ToString() is indeed virtual, and that's great since it lets you do things like string formatting more easily. The default implementation returns the type name, so if you call ToString() on b above you get the name. If you override the method you get whatever you return in the overridden method. Obviously there's no code in object.ToString() that somehow obtains a reference to the instance of type B and calls ToString() on it. The reason it works is because the code generated for ToString() isn't a normal method call, but a lookup in the VMT for the type (B in this example) and then a dynamic invokation. This allows you to write code today that call methods you only create in the future, perhaps in another assembly. Method hiding however is really not much more than having two types that both have a method with the same name. ;P

dojohansen

I completely agree with Booch. While people may use words whatever way they like as far as I'm concerned, "polymorphism" loses it's meaning if the interface changes. Technically there's no difference between methods f() and g() compared to f() and f(int). They're simply different methods. Overloads are useful, but only for the human users of the code. If I offer multiple ways to do the same thing, such as specify a timeout using either the number of milliseconds (int) or a TimeSpan, it is obviously easier for the user to cope with two methods with the same name instead of getting potentially far more method names in his intellisense list. But that is also the extent of it's usefulness - it has nada to do with polymorphism/virtual method invokation/late binding. I suppose my opinion ought to be expected if you read my entries elsewhere in this thread. :)