Overloading a concept of polymorphism or?

Question

Public class John {

public void setValue(){
   this.value = 0;
}
public void setValue(int v){
   this.value = v;
}

Now potentially how would i call these two methods??

John j = new John();
j.setValueO();
j.setValue(10);

Correct me if i am wrong.

Is function overloading a concept of polymorphism? If not, under which OOP branch does this come.
Encapsulation means Hiding the information and Abstraction means Hiding the implantation details. So when i do overload a method, do i carry anything on these two above... {Abstraction and Encpsulation}
Is Overloading compile time or runtime? Why do they call this for overloading and overriding?

Take a look at the answers here: http://stackoverflow.com/questions/154577/polymorphism-vs-overriding-vs-overloading — , Sep 04 '11 at 00:32
[Types of Polymorphism](http://stackoverflow.com/a/11732581/697630) — Edwin Dalorzo, Dec 16 '12 at 13:56

score 2 · Accepted Answer · answered Sep 04 '11 at 01:03

Yes you are right, expect the typo which you have made?

Is function overloading a concept of polymorphism? If not, under which OOP branch does this come.

Well speaking from historical point of view, it does come but still many argue that its not a form of polymorphism.

Overloading

The method functions differently based on the arguements.

Overriding

The method functions differently based on which class was used to instainate it.The method bark could sound differently for Class CAT and Class DOG.

Encapsulation means Hiding the information and Abstraction means Hiding the implantation details. So when i do overload a method, do i carry anything on these two above... {Abstraction and Encpsulation}

Nope. May be someone can answer on this much clearer.

Is Overloading compile time or runtime? Why do they call this for overloading and overriding?

Compile time. In overriding the decision that method of which class is to be called is decided at runtime, hence it is runtime.

In overloading the method definition, availability based on the parameters passed in the method call is checked at compile time only.

score 2 · Answer 2 · answered Sep 04 '11 at 01:03

Java does not identify methods by their names alone, but by their signatures. A signature is composed of the method name and the ordered list of parameter types. So, from a compiler and jvm point of view, those are two completely different methods. The fact that they share the name (and as a consequence a similar signature) has no meaning if not for humans.

Since signatures are used in .class files, the compiler is responsible for computing the signature of a method call, using method name and parameters, at compile time. The late binding that happens at runtime is related to polymorphism, beacuse the current instance on which a certain method is called could be an instance of a subclass that override a certain method, wether that method is also overloaded or not, in java, is not considered by the runtime at all.

You cannot have two method with the same signature in the same class. Notably, the return type of a method is not part of its signature, so you cannot have two method with the same and and same parameters but returning two different types.

In other languages, javascript for example, since parameters are always dynamic, the signature is only composed of the name of the method, which makes overloading impossible

score 1 · Answer 3 · answered Sep 04 '11 at 00:31

As to the first part of your question, yes the code you showed is an example of overloading, well, assuming the first part is correct and the 0 in the second part is a typo.

I'm not familiar with how these topics are formally taught these days, but to my mind overloading isn't really related to polymorphism. It's just a convenient way for methods that more or less do the same thing (and often call each other) to share a name. I have no idea how to answer your second question. What is an "OOP branch"?
Again, I'm not quite sure how these tie in. Doesn't it depend on what the method actually does?
Well, think about it this way. In Java, when you call a method in general, leaving overloading aside, at what phase does the system figure out which method you're calling (as opposed to which class's implementation of that method)? As to the origin of those terms, honestly that should be pretty easy to look up.

score 1 · Answer 4 · answered Sep 04 '11 at 00:47

Since function overloading can work very well without objects, I do not see any reason for it to be an OOP concept at all. For the question whether it's polymorphism, it does fulfill the general requirements and according to Wikipedia is a form of polymorphism.
In general, when you create a method you always do both (you abstract away some general functionality and you hide the information of the internal workings of the function). Overloading does not add to neither, IMO. (Even though through overloading and the gained polymorphism you could argue to gain in abstraction, since the function becomes more generic, it is IMO still on the same level of abstraction.)
Overload resolution is - which was suprising to me at first - compile time. This is in contrast to the mentioned overriding. (So its in that sense not the same kind of polymorphism, as one is runtime and the other one is compile time.)

Overloading a concept of polymorphism or?

4 Answers4