Function overloading

Not to be confused with Instruction overlapping, Overlay (programming), or Method overriding.

In some programming languages, function overloading or method overloading is the ability to create multiple functions of the same name with different implementations. Calls to an overloaded function will run a specific implementation of that function appropriate to the context of the call, allowing one function call to perform different tasks depending on context.

For example, doTask() and doTask(object o) are overloaded functions. To call the latter, an object must be passed as a parameter, whereas the former does not require a parameter, and is called with an empty parameter field. A common error would be to assign a default value to the object in the second function, which would result in an ambiguous call error, as the compiler wouldn't know which of the two methods to use.

Another example is a Print(object o) function that executes different actions based on whether it's printing text or photos. The two different functions may be overloaded as Print(text_object T); Print(image_object P). If we write the overloaded print functions for all objects our program will "print", we never have to worry about the type of the object, and the correct function call again, the call is always: Print(something).

Languages supporting overloading

Languages which support function overloading include, but are not necessarily limited to, the following:

• Ada
• Apex
• C++
• C#
• Clojure ^[1]
• Swift
• Fortran
• Kotlin ^[2]
• Java ^[3]
• Julia
• PostgreSQL ^[4] and PL/SQL ^[5]
• Scala
• TypeScript
• Visual Basic (.NET)
• Wolfram Language
• Elixir
• Nim ^[6]
• Crystal ^[7]
• Delphi ^[8]

Rules in function overloading

• The same function name is used for more than one function definition in a particular module, class or namespace
• The functions must have different type signatures, i.e. differ in the number or the types of their formal parameters (as in C++) or additionally in their return type (as in Ada). ^[9]

Function overloading is usually associated with statically-typed programming languages that enforce type checking in function calls. Overloaded function is really just a set of different functions that happen to have the same name. For any particular call, the compiler determines which overloaded function to use, and resolves this at compile time. This is true for programming languages such as Java. ^[10]

Sometime overloading wrongly taken as a classification of static polymorphism in which a function call is resolved using some "best match" algorithm, where the particular function to call is resolved by finding the best match of the formal parameter types with the actual parameter types or/and number of parameters. The mistake comed from confusion in each form of static polymorphism as following:

• Parametric polymorphism differs from overloading by that the function definition exists only ones and this function invoked with parameters of different types which are substituted formal parameter types.
• Ad hoc polymorphism is very similar to overloading but it's depends of a language. This classification was introduced by Christopher Strachey in 1967, but difference is that he applied for compiler specific features which was exists in some programming languages. It was possibly to define in a module only name of a function and have in another module a multiple functions with same name(exact function overloading) so one module doesn't have access to another module until compiled. Thus was created effect that in first module was used same function for different parameters but it was just a cosmetic effect therefore Christopher Strachey gave it such special name as "ad hoc". But not any language has same feature, e.g. in Java, there is no possibility define such function, similar example in Java can be achieved by using common interface for both modules but interface should have exact function signature thus Ad hoc polymorphism can't be applied.

Function overloading differs from forms of polymorphism where the choice is made at runtime, e.g. through virtual functions, instead of statically.

Example: Function overloading in C++

#include<iostream>intVolume(ints){// Volume of a cube.returns*s*s;}doubleVolume(doubler,inth){// Volume of a cylinder.return3.1415926*r*r*static_cast<double>(h);}longVolume(longl,intb,inth){// Volume of a cuboid.returnl*b*h;}intmain(){std::cout<<Volume(10);std::cout<<Volume(2.5,8);std::cout<<Volume(100l,75,15);}

In the above example, the volume of each component is calculated using one of the three functions named "volume", with selection based on the differing number and type of actual parameters.

Constructor overloading

Constructors, used to create instances of an object, may also be overloaded in some object-oriented programming languages. Because in many languages the constructor's name is predetermined by the name of the class, it would seem that there can be only one constructor. Whenever multiple constructors are needed, they are to be implemented as overloaded functions. In C++, default constructors take no parameters, instantiating the object members with their appropriate default values, "which is normally zero for numeral fields and empty string for string fields". ^[11] For example, a default constructor for a restaurant bill object written in C++ might set the tip to 15%:

Bill():tip(0.15),// percentagetotal(0.0){}

The drawback to this is that it takes two steps to change the value of the created Bill object. The following shows creation and changing the values within the main program:

Billcafe;cafe.tip=0.10;cafe.total=4.00;

By overloading the constructor, one could pass the tip and total as parameters at creation. This shows the overloaded constructor with two parameters. This overloaded constructor is placed in the class as well as the original constructor we used before. Which one gets used depends on the number of parameters provided when the new Bill object is created (none, or two):

Bill(doubletip,doubletotal):tip(tip),total(total){}

Now a function that creates a new Bill object could pass two values into the constructor and set the data members in one step. The following shows creation and setting the values:

Billcafe(0.10,4.00);

This can be useful in increasing program efficiency and reducing code length.

Another reason for constructor overloading can be to enforce mandatory data members. In this case the default constructor is declared private or protected (or preferably deleted since C++11) to make it inaccessible from outside. For the Bill above total might be the only constructor parameter – since a Bill has no sensible default for total – whereas tip defaults to 0.15.

Complications

Two issues interact with and complicate function overloading: Name masking (due to scope) and implicit type conversion.

If a function is declared in one scope, and then another function with the same name is declared in an inner scope, there are two natural possible overloading behaviors: the inner declaration masks the outer declaration (regardless of signature), or both the inner declaration and the outer declaration are both included in the overload, with the inner declaration masking the outer declaration only if the signature matches. The first is taken in C++: "in C++, there is no overloading across scopes." ^[12] As a result, to obtain an overload set with functions declared in different scopes, one needs to explicitly import the functions from the outer scope into the inner scope, with the using keyword.

Implicit type conversion complicates function overloading because if the types of parameters do not exactly match the signature of one of the overloaded functions, but can match after type conversion, resolution depends on which type conversion is chosen.

These can combine in confusing ways: An inexact match declared in an inner scope can mask an exact match declared in an outer scope, for instance. ^[12]

For example, to have a derived class with an overloaded function taking a double or an int, using the function taking an int from the base class, in C++, one would write:

classB{public:voidF(inti);};classD:publicB{public:usingB::F;voidF(doubled);};

Failing to include the using results in an int parameter passed to F in the derived class being converted to a double and matching the function in the derived class, rather than in the base class; Including using results in an overload in the derived class and thus matching the function in the base class.

Caveats

If a method is designed with an excessive number of overloads, it may be difficult for developers to discern which overload is being called simply by reading the code. This is particularly true if some of the overloaded parameters are of types that are inherited types of other possible parameters (for example "object"). An IDE can perform the overload resolution and display (or navigate to) the correct overload.

Type-based overloading can also hamper code maintenance, where code updates can accidentally change which method overload is chosen by the compiler. ^[13]

See also

• Abstraction (computer science)
• Constructor (computer science)
• Default argument
• Dynamic dispatch
• Factory method pattern
• Method signature
• Method overriding
• Object-oriented programming
• Operator overloading

Citations

1. "Clojure - Learn Clojure - Functions". clojure.org. Retrieved 2023-06-13.
2. "Kotlin language specification". kotlinlang.org.
3. Bloch 2018, p. 238-244, §Chapter 8 Item 52: Eliminate unchecked warnings.
4. "37.6. Function Overloading". PostgreSQL Documentation. 2021-08-12. Retrieved 2021-08-29.
5. "Database PL/SQL User's Guide and Reference". docs.oracle.com. Retrieved 2021-08-29.
6. "Nim Manual". nim-lang.org.
7. "Crystal Docs". crystal-lang.org.
8. "Embarcadero Delphi". embarcadero.com.
9. Watt, David A.; Findlay, William (1 May 2004). Programming Language Design Concepts. John Wiley & Sons, Inc. pp. 204–207. ISBN   978-0-470-85320-7.
10. Bloch 2018, p. 238-244, §Chapter 8 Item 52: Use overloading judiciously.
11. Chan, Jamie (2017). Learn C# in One Day and Learn It Well (Revised ed.). p. 82. ISBN   978-1518800276.
12. Stroustrup, Bjarne. "Why doesn't overloading work for derived classes?".
13. Bracha, Gilad (3 September 2009). "Systemic Overload". Room 101.

References

• Bloch, Joshua (2018). "Effective Java: Programming Language Guide" (third ed.). Addison-Wesley. ISBN   978-0134685991.

External links

• Meyer, Bertrand (October 2001). "Overloading vs Object Technology" (PDF). Eiffel column. Journal of Object-Oriented Programming. 14 (4). 101 Communications LLC: 3–7. Retrieved 27 August 2020.