Extension methods

[Ethan McCue]

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/e0fb8eb4/attachment-0001.htm>