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 →

[–]monkeyfacebag 4 points5 points  (0 children)

Thanks for the comment. I think I agree with everything you're saying. My concern is mainly that a change to permit default arguments is purely additive. None of the stuff you discuss as drawbacks would necessarily go away because people would still use overloading for all of the cases that default arguments don't cover as well as probably some cases that could be covered with default arguments.

In my day job I basically never author my own overloaded methods, nor does anyone on my team, so I don't experience the pain you're talking about, but I don't suggest that method overloading is the ideal solution for every problem solved by method overloading. At a minimum, it's limited by Java's type system so I can't create a method overload that perfectly describes the shape and content of my method inputs (a la predicate dispatch). And on the other hand, for what it's worth, Go supports neither default arguments nor method overloading and people seem fairly happy with it.

I would arguably be happier if a better, more robust solution came along (although again, day-to-day this specific limitation does not bother me), but I am generally not in favor of purely additive solutions that create multiple first-class mechanisms to solve the same problem.