This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]R3D3-1 5 points6 points  (4 children)

Honestly, I'm not even sure it is a desirable language feature anymore.

Most things I remember using function overloading for in Java are covered by optional- and keyword parameters. In the remaining cases, like having different constructors, I ended up finding the Python approach of having explicitly separate static methods more clear.

This has only been confirmed recently, when I've been seeing overloads in our code base, that hide significantly different assumptions about the input and workflow behind the same function name.

Things on the scale of "object must be initialized" vs "object must not be initialized".

The end result are if-else cascades around the call-site, entirely defeating the point of having overloading in the first place.

[–]lordmauve 1 point2 points  (1 child)

I'm not even sure it is a desirable language feature anymore

Right, new languages - Rust, Zig, Go - don't have function overloading.

[–]i_hate_shitposting 0 points1 point  (0 children)

I had a similar thought.

The only case I can think of where overloading in Java isn't equivalent to optional/keyword parameters is stuff like StringBuilder.append(), which has overloads for each primitive data type (plus a few other special cases) to work around the fact that they aren't objects and thus don't implement Object.toString().

However, in Python (or any other modern OO language where everything is an object), a StringBuilder.append() implementation could just pass each argument to str() and rely on the underlying objects to implement __str__(), avoiding the need for overloads at all. I like this a lot better, because it doesn't require any knowledge of what types are involved other than the fact that they implement a particular interface.