I’m saying that when the project gets big, and each of those methods get long, A developer who is new to the project might have some confusion as to why there are methods with the same exact name inside of a class.
Ah. Since they’re targeting host applications written in C or C++, I doubt their target demographic would be unfamiliar with function overloading though.
It’s not like one has to use a feature just because it exists, so if it’s really an issue just… don’t?
This might confuse a lot of people
class Unicorn { prance() { System.print("The unicorn prances in a fancy manner!") } prance(where) { System.print("The unicorn prances in %(where).") } prance(where, when) { System.print("The unicorn prances in %(where) at %(when).") } }It’s not obvious to me what you mean, exactly. What do you find confusing about it?
I’m saying that when the project gets big, and each of those methods get long, A developer who is new to the project might have some confusion as to why there are methods with the same exact name inside of a class.
Ah. Since they’re targeting host applications written in C or C++, I doubt their target demographic would be unfamiliar with function overloading though.
It’s not like one has to use a feature just because it exists, so if it’s really an issue just… don’t?
This is common on OOP.
https://en.wikipedia.org/wiki/Function_overloading
Yes. Which frequently leads to complications.
#include <iostream> using namespace std; void log(int level) { cout << "Logging numeric level: " << level << endl; } void log(string message) { cout << "Logging message: " << message << endl; } int main() { log('A'); // Uh oh — which one is this? }The level one. But that’s more due to implicit casting rather than function overloading imo.