Fluent: Static Extension Methods for Java

Re:Fluent: Static Extension Methods for Java by littlecranky67 on Monday July 03, 2023 @03:44AM (#36570007)

Extension methods have been available in C# since C# 3.0 (released 2007) and a great addition IMHO. In recent .NET versions, especially ASP.NET, they are heavily relied upon for core framework tasks. Wonder why Java never got them officially.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @03:57AM (#36570087)

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.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by throwaway2037 on Monday July 03, 2023 @04:37AM (#36570331)

    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.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @04:41AM (#36570356)

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.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by hyperpape on Monday July 03, 2023 @04:42AM (#36570362)

Brian Goetz has written on the subject. 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.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by rogerkeays on Monday July 03, 2023 @05:12AM (#36570555)

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.

[ Parent | on HN ]

Re:Fluent: Static Extension Methods for Java by zeedude on Monday July 03, 2023 @09:08AM (#36572357)

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.

[ Parent | on HN ]