Re:Ask HN: What programming feature can't you live without?
by ekimekim on Tuesday May 02, 2017 @07:32PM
(#14251678)
In my experience, most cases of overloading are trying to achieve one of two things:
* An argument with a default value: foo(string bar), foo(string bar, string baz)
* An argument which can be of two or more types: foo(string bar), foo(byte[] bar)
I believe the first problem is better solved by an optional/default argument language feature (or in a pinch, a sentinel value).
I believe the second problem is better solved by either using a dynamic language, or an expressive type system that lets you say what you mean, either via polymorphism or union types.
For the remaining cases it's probably acceptable to have a second function with a slightly different name.
While we're on the subject: Keyword-specified arguments are a major quality-of-life improvement, especially once you have large signatures with many defaults. I see no reason why all languages shouldn't adopt python-style foo(x, y, abc=123, xyz=456). DoThing(myflag=False) is generally much clearer than DoThing(False).
* An argument with a default value: foo(string bar), foo(string bar, string baz)
* An argument which can be of two or more types: foo(string bar), foo(byte[] bar)
I believe the first problem is better solved by an optional/default argument language feature (or in a pinch, a sentinel value).
I believe the second problem is better solved by either using a dynamic language, or an expressive type system that lets you say what you mean, either via polymorphism or union types.
For the remaining cases it's probably acceptable to have a second function with a slightly different name.
While we're on the subject: Keyword-specified arguments are a major quality-of-life improvement, especially once you have large signatures with many defaults. I see no reason why all languages shouldn't adopt python-style foo(x, y, abc=123, xyz=456). DoThing(myflag=False) is generally much clearer than DoThing(False).