Extension methods

Tue Apr 23 07:35:17 UTC 2024

Well that's just really frustrating for me.

I am pretty sure the point I will provide as advantages has already been
brought up here numerous times, but I will take some time and would
appreciate it if someone from API designers, who once rejected this
proposal, would spare some time to discuss this topic with me.

1. "Poor reflective discoverability" essentially means extension methods
are not accessible when inspecting class members. That is not some
inherent issue of this feature, this is just the way it should be. I'm
not really sure if there is someone who has ever been hurt by this, besides
maybe some parser-based solutions, but let's be honest, this is a:
solvable, b: ridiculously exotic to consider.

2. Documentation accessibility is a strange point for me to be fair. Every
IDE nowadays is capable of fetching the right documentation, as well as
explicitly mentioning where the method comes from, as it is done in C#,
kotlin, swift and many other languages. I don't think anyone has ever heard
complaints about poor documentation of LinQ. Unless someone is writing in
notepad, this is poorly applicable.

3. Not overridable. Should they be? I don't think there is a way to achieve
some kind of "polymorphic" extensions, and I don't think there should be:
extension methods should provide polymorphic target handling, floow LSP
etc., not the other way around.

4. C# extension methods indeed have some very serious drawbacks compared to
Java's, but doesn't this also go the other way around? Canonical utility
functions breach object-oriented code-style, making users write procedural
code like Utils.doSome(obj, params) instead of obj.doSome(params). Its
common issue users just aren't aware of the existence of certain utility
classes and end up with nonoptimal code.
Code without extension methods is always much more verbose, if the API is
supposed to be fluent developer could end up with deep nested invocations.
This brings numerous problems, such as majorly reduced readability, as the
utility methods wrap each other and the developer reads the processing
pipeline "from the end". Also reduced readability always means increased
change of errors.
Writing code using utility methods instead of extensions is just slower,
developers have to waste more time writing a statement than it would be
with extension methods.
Some other advantages I will list below, after this list is ended.

5. One of the answers from the first thread you provided (
https://stackoverflow.com/a/29494337) states that omitting extension
methods is a "philosophical choice", as API developers should define
the API. I have to strongly disagree with that. Extension methods are NOT
part of the API, they are EXTENSION to it. It does not breach
encapsulation as it can't access any internal members of API classes.
Extensions have to be imported explicitly (not the containing class), so
they are explicitly mentioned in the imports list. Also, are utility
methods also breaching this rule then? The only real difference I see is
differences in notation, and extension methods are clearly much more
concise.

Now moving on to some of my personal points. I am also developing some core
libs APIs, and sometimes extension methods are just craving to be used.
Modifying widely-used interfaces is always painful, but that's the only way
to provide a concise way to communicate with existing APIs. Moreover, Java
is an old language and some internal implementations of APIs, like Stream
implementations, are so juncted that adding something new to these classes
directly becomes a spec-ops task. Some APIs, like Gatherer API or Collector
API, arise just from this simple necessity to introduce new behaviour
without modifying extended class itself.

Extension methods are de-facto standard for modern languages: C#, Kotlin,
Swift, Rust and any other modern language provide this option. JS also has
its own unique way of extending APIs. The only modern widely-used language
that does not have extension methods is Python, but that only applies to
built-ins, custom classes could be extended as well. When Java refuses to
introduce this feature, I suffer major damage in the eyes of potential
switchers from ANY other language available right now, which is retrograde
and, as for me and any other supporter of Java, really upsetting.

Introduction of extension will not invalidate previously written code: if
one wants, they can still use utilities as earlier and pretend that nothing
happened. However, for other, significant, if not to say major, part of the
community, this would be a valuable addition..Virtually every Java utility
library: lombok, manifold, xtend - provide extension method functionality,
which clearly shows there is a demand for a feature.

The extension methods are just syntax sugar, nothing more. They provide
better developer experience, make code less verbose and more readable,
which reduces chance of errors and helps to develop apps faster, while not
affecting performance in any way, which is crucial in today's world and may
be a major concurrent advantage.

Also, last but not least, noone from Java developers teams will have to put
efforts into implementation. I am willing to take one full feature
development lifecycle, from drafts to testing and integration. Of course,
final changes will need to be reviewed, but I don't think this will be an
unbearable burden. Regarding implementation, these changes are really
non-invasive, and are really unlikely to introduce any issues, it already
passes all existing tests.

I sincerely hope this letter will bring up this discussion once again, as I
am open for dialogue, but I am standing my ground about numerous advantages
this feature has. If that's possible, I may file a draft JEP and let the
community vote for or against it, to see what Java users think about this
proposal.

Best regards,
Hoping to receive some feedback

вт, 23 апр. 2024 г. в 07:01, Ethan McCue <ethan at mccue.dev>:

> This subject has been addressed publicly by the language team at
> various points. These are just a few I found, I'm sure there is more
> elaboration out there.
>
> Implementation choices aside, the API of "add a static method and mark it
> as an "extension method", call like instance method" seems to have been
> rejected.
>
> > C# extension methods have some very serious drawbacks compared to Java's
> default methods (for example, poor reflective discoverability, poor
> discoverability through documentation, not overrideable, require ad-hoc
> conflict-management rules)
>
>
> https://stackoverflow.com/questions/29466427/what-was-the-design-consideration-of-not-allowing-use-site-injection-of-extensio
>
> > What I believe you are hoping for is the ability to "monkey-patch" a
> method into a class you do not control, but Java does not give you that (by
> design; it was considered and rejected.)
>
>
> https://stackoverflow.com/questions/24096421/java-8-add-extension-default-method-to-class
>
>
> On Mon, Apr 22, 2024 at 7:24 PM ІП-24 Олександр Ротань <
> rotan.olexandr at gmail.com> wrote:
>
>> Subject: Proposal for Introducing Extension Methods to Java
>>
>> Dear Java Development Team,
>>
>> I hope this email finds you all in good spirits. I am writing to propose
>> the integration of extension methods into the Java programming language, a
>> feature that I believe holds considerable promise in enhancing code
>> readability and maintainability.
>>
>> Extension methods offer a means to extend the functionality of existing
>> classes in a manner that aligns with Java's principles of static typing and
>> object-oriented design. The proposed syntax, exemplified as follows:
>>
>> public static void extensionMethod(extends String s) { ... }
>>
>> adheres to established conventions while providing a concise and
>> intuitive means of extending class behavior. Notably, the use of the
>> `extends` keyword preceding the type parameter clearly denotes the class to
>> be extended, while the method itself is declared as a static member of a
>> class.
>>
>> I wish to emphasize several advantages of extension methods over
>> traditional utility functions. Firstly, extension methods offer a more
>> cohesive approach to code organization by associating functionality
>> directly with the class it extends. This promotes code clarity and reduces
>> cognitive overhead for developers, particularly when working with complex
>> codebases.
>>
>> Secondly, extension methods enhance code discoverability and usability by
>> integrating seamlessly into the class they extend. This integration allows
>> developers to leverage IDE features such as auto-completion and
>> documentation tooltips, thereby facilitating more efficient code
>> exploration and utilization.
>>
>> Lastly, extension methods promote code reusability without the need for
>> subclassing or inheritance, thereby mitigating the risks associated with
>> tight coupling and inheritance hierarchies. This modularity encourages a
>> more flexible and adaptable codebase, conducive to long-term
>> maintainability and scalability.
>>
>> In light of these benefits, I believe that the integration of extension
>> methods into Java would represent a significant step forward for the
>> language, aligning it more closely with modern programming paradigms while
>> retaining its core strengths.
>>
>> I am eager to discuss this proposal further and collaborate with you all
>> on its implementation. Your insights and feedback would be invaluable in
>> shaping the future direction of Java development.
>>
>> Thank you for considering this proposal. I look forward to our discussion.
>>
>> The draft implementation can be found in the following branch of the
>> repository: https://github.com/Evemose/jdk/tree/extension-methods. I am
>> new to Java compiler development, so any tips or remarks about what I have
>> done in the wrong way or in the wrong place. I will add complete test
>> coverage a bit later, but for now, there is "jdk" archive in the root
>> directory of repo, which contains built in jdk for windows x86-64. If
>> someone is willing to participate in testing as user, I would appreciate
>> any help.
>>
>> Best regards
>>
>> PS: Note about internal implementation: it introduces a new flag -
>> EXTENSION, that is equal to 1L<<32. It seems like it takes the last vacant
>> bit in a long value type that has not been taken by flags. Not sure what
>> the compiler development community should do about this, but it feels like
>> it could be an obstacle to new features that might be introduced later.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240423/19792072/attachment-0001.htm>