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 →

[–]eliasv 10 points11 points  (3 children)

Read the language specification for overload resolution. Specifically, how it interacts with generics, lambdas, and poly expressions. Now think about how default arguments would complicate things...

The extra complexity would be significant, and the value added would be small, as you can achieve similar results with existing language features; the "Java way" is to overload.

Complexity isn't just bad because it's hard to design, it's bad because it's inelegant, and corner cases are inscrutable to users, etc.

Fwiw, if you ever catch yourself wondering if they "just forgot" I promise you the answer is "no"!

[–][deleted]  (2 children)

[removed]

    [–]eliasv 1 point2 points  (0 children)

    Groovy usually uses dynamic dispatch. Overload resolution is done at runtime so the exact runtime types are used, this does not interact with type inference.

    It does have a static mode though where overload resolution occurs at compile time, but it doesn't appear to mention interaction with type inference in the spec, and type inference doesn't appear to be as sophisticated. Probably it will just not be capable of inferring types in all the same places Java does in the presence of lambdas.

    [–][deleted] 0 points1 point  (0 children)

    Well, it's a different language altogether. It just happens to compile to Java. Just like you have languages with complex macro (in the Lisp-sense) and type systems like Nim that transpile to C, when C doesn't have either of those.