3 ms·

I can only speculate, but I think it is because extension methods can be shadowed if a vendor adds a method of the same name to the class you are extending. Of

I can only speculate, but I think it is because extension methods can be shadowed if a vendor adds a method of the same name to the class you are extending. Of course, that depends on how you resolve methods. In java, this would be a compile time problem, because once the class is compiled the extension method is called with `invokestatic` rather than `invokevirtual` used by class methods. There is also a healthy fear of change in the java community that could explain it.

throwaway2037 3y ago
There is also a healthy fear of change in the java community that could explain it. Nice jab at the end! Java (well, really Sun, then Oracle) prioritises backwards compatibility over every other goal. So, does Win32 API. Does DotNet do the same? I'm unsure. This also explains why it took so long for Java to get lambdas. And, generics with primitive types, e.g., ArrayList<int>, via Project Valhalla. It is a super hard problem to upgrade Java without breaking old stuff. Hence, it is a multi-year R&D effort.
- rogerkeays 3y ago
  Yeh, backwards compatibility is one of the biggest selling points of Java. Hopefully, Fluent will show that we can change one or two lines of compiler code and not burn down the whole house. We'll see.
hyperpape 3y ago
Brian Goetz has written on the subject. https://stackoverflow.com/a/29494337 https://stackoverflow.com/a/29494337 I think you can’t look at the past 5 years and the features that are being floated for Java 21 and future releases and think fear of change is the issue—the language is now changing rapidly.
- rogerkeays 3y ago
  Thanks for the link. I've been trying to find the canonical answer to this question myself. There's the philosophical standpoint: API designers should control their APIs, and the technical: poor reflective discoverability, poor discoverability through documentation, not overrideable, require ad-hoc conflict-management rules. I like his use of the word should, because as we all know it really means won't. I should exercise more, I should stop trolling people on reddit. API designers should control their APIs. As for the technical objections, I think the conflict-management rules hold the most weight, but this problem is no more difficult than any other in language design. "not overrideable" is a feature, not a bug (can we please give up on behavioural inheritance already?), and discoverability already sucks. I mean, I still use duckduckgo to find javadocs.
  - zeedude 3y ago
    My sentiments exactly. The “API designers should control their APIs” one is my favorite and one of the more ridiculous things I’ve heard him say, which is saying something. It’s beyond humor, though, that all of his reasons are fallacies.

throwaway2037 3y ago

There is also a healthy fear of change in the java community that could explain it. Nice jab at the end! Java (well, really Sun, then Oracle) prioritises backwards compatibility over every other goal. So, does Win32 API. Does DotNet do the same? I'm unsure. This also explains why it took so long for Java to get lambdas. And, generics with primitive types, e.g., ArrayList<int>, via Project Valhalla. It is a super hard problem to upgrade Java without breaking old stuff. Hence, it is a multi-year R&D effort.

rogerkeays 3y ago
Yeh, backwards compatibility is one of the biggest selling points of Java. Hopefully, Fluent will show that we can change one or two lines of compiler code and not burn down the whole house. We'll see.

hyperpape 3y ago

Brian Goetz has written on the subject. https://stackoverflow.com/a/29494337 https://stackoverflow.com/a/29494337 I think you can’t look at the past 5 years and the features that are being floated for Java 21 and future releases and think fear of change is the issue—the language is now changing rapidly.

rogerkeays 3y ago
Thanks for the link. I've been trying to find the canonical answer to this question myself. There's the philosophical standpoint: API designers should control their APIs, and the technical: poor reflective discoverability, poor discoverability through documentation, not overrideable, require ad-hoc conflict-management rules. I like his use of the word should, because as we all know it really means won't. I should exercise more, I should stop trolling people on reddit. API designers should control their APIs. As for the technical objections, I think the conflict-management rules hold the most weight, but this problem is no more difficult than any other in language design. "not overrideable" is a feature, not a bug (can we please give up on behavioural inheritance already?), and discoverability already sucks. I mean, I still use duckduckgo to find javadocs.
- zeedude 3y ago
  My sentiments exactly. The “API designers should control their APIs” one is my favorite and one of the more ridiculous things I’ve heard him say, which is saying something. It’s beyond humor, though, that all of his reasons are fallacies.