Why Polymorphism Deserves a Second Article

There are a number of reasons why things have a sequel. Books are written in multiple parts because sometimes it just takes too long for the next book to be written. Movies usually have a part 2, 3 or even a part 6 because they really hit it big in the box office. The same goes for video games that are really fun and have an excellent following of players. But my reason for writing a second article is different. In the first article, I explained that overloading CAN be a form of polymorphism. Now, I’m going to explain WHY I’ve changed my mind.

Operator Overloading Is Not Really Overloading

Operators are polymorphic, but operator overloading is not really overloading. Therefore, overloading CANNOT be polymorphic. You can think of operators as interface methods named like, + – * /, and since they’re interface methods they have no implementation. The actual “adding” of the ‘+’ method is implemented at the parameter type level. The method is invoked once operands of that type are used with the operator. With operator overloading, there is no real overloading that takes place. Overloading is defined as methods that have the same name, but have different parameter signatures. Having methods of the same name residing in different classes, is obviously not overloading.

Why Developers Think Overloading Itself is Polymorphic

Whoever came up with the term operator overloading made a crucial mistake. True, it does look like you’re overloading a method operator by allowing multiple versions of it, as long as they have different parameter types. But why would this be overloading when the methods are not in the same place? Whoever coined the term caused a wave of misconception. Developers started seeing operator overloading as polymorphic. After that, they started thinking overloading itself was polymorphic, even though there was really no overloading that took place. But if you look deeply into how it is implemented, you will definitely be convinced it is not overloading at all, but rather interface implementation that is taking place. We should start calling it “operator implementation”, which I honestly think sounds better.

Thus, “I just created a Roman numeral class and I now want to provide an operator implementation for adding.”

Polymorphic Methods Should Belong to Different Types

Of course all my assumptions are based on how it is implemented in .NET. What if we examine this scenario in a different language? For example, if operator overloading is implemented at just one level, we would have an arbitrary class containing all the operators as methods. So, now the methods are overloaded. Is it polymorphic? The answer is still NO. Overloading fails to satisfy an important characteristic of polymorphism. Polymorphic methods should belong to different types. The reason something is polymorphic is because you don’t really know what it is going to do at different levels. Overloading only happens at one level and with the same type. The reality is – overloading is nothing but syntactic sugar that has been added, so that you’d think it has polymorphic behavior. It’s just a way to reuse the same method name.

Parametric Polymorphism

Let me debate with myself, a little bit. Since operator overloading is the closest thing to polymorphism with regard to overloading (just because the word happens to be there), hypothetically, operators can be polymorphic if they were implemented with parametric polymorphism. As discussed previously, parametric polymorphism hinges on having polymorphic parameters bound to be of similar type. Operators, in fact fit these criteria, if they are to be implemented with generics. It would look weird though having to “add” two generic parameters + (looks like an emoticon to me), but it would certainly work. Parametric polymorphism is polymorphic because of its parameters and not because of the method per se. The same would apply to this kind of implementation of operator overloading, thus making it polymorphic.