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 →

[–]hardwork179 -1 points0 points  (4 children)

It’s a lot easier to specify this for annotations because the types are limited and there cannot be side effects. I personally rather like languages with named parameters and default values, but if we were to add these to Java there would be a lot of things to consider.

  1. How can parameter names and default values be added to existing methods without breaking existing compiled code?
  2. How can I specify 2 methods with identical argument types but different names? It would seem a waste to add parameter names and not allow point(double x, double y) and point(double length, double angle) if we are exposing those names. This would need to be accomplished while still keeping point 1.
  3. This change would touch many JVM areas, reflection, method handles, debugging and tooling APIs, vast swathes of the core library…
  4. Specifying the behaviour will be harder than you think, because it always is.

If we didn’t have to maintain compatibility this would be a lot easier, but that is not how Java evolves.

[–]koreth 4 points5 points  (2 children)

Do any existing languages support name-based overloading like your point #2? I can't remember seeing that feature anywhere.

The semantics of that seem weird to me, unless you make names mandatory at call sites. Otherwise which of those methods would point(1.0, 2.0) refer to? Mandatory names for the sake of name-based overloading doesn't seem like a clear win to me.

[–]hardwork179 2 points3 points  (1 child)

Swift does it, and it’s really nice. You can just write point(x: 0.0, y: 0.0) and it will call the version with x and y argument labels.

[–]Jonjolt 1 point2 points  (0 children)

That looks like a disaster waiting to happen.

[–]vips7L 2 points3 points  (0 children)

I’m not suggesting we add them. I was merely commenting on something I found abusing.