Extension methods

[ІП-24 Олександр Ротань]

Actually, that what I have thought about. This is a good way to find
compromise, I thought about syntax like obj>ext(), which implies object is
"injecting" into utility method. However, this introduces a new syntax, and
as I reckon, Java is going for the most simple syntax possible, and this
might still clash with it.

Other thing that I have thought of is that some extensions (like previously
mentioned LinQ), actually *should* look like an API itself, as they are
extension provided by the same team that made an API. There could be some
ways to achieve this like allowing dot syntax for extensions from same
module and arrow from any outer, so there are something like trusted and
untrusted extensions, but this adds new concepts to language, which is also
udesirable.

Although, I am glad to see that this idea is still not discarded
completely. I agree that the place where extensions are the most needed is
fluent apis like streams, that could contain many operations in chain, and
nesting makes code barely readable. As I understand, readability is what
Java going for, so with some adjustments, such feature could enhance
readability in some cases while not damaging it in another. The syntax
Anatoly proposed could be a point where there are virtually aren't any
major cons, while preserving all the pros.

On Wed, Apr 24, 2024, 23:32 ІП-24 Олександр Ротань <rotan.olexandr at gmail.com>
wrote:

> Actually, that what I have thought about. This is a good way to find
> compromise, I thought about syntax like obj>ext(), which implies object is
> "injecting" into utility method. However, this introduces a new syntax, and
> as I reckon, Java is going for the most simple syntax possible, and this
> might still clash with it.
>
> Other thing that I have thought of is that some extensions (like
> previously mentioned LinQ), actually *should* look like an API itself, as
> they are extension provided by the same team that made an API. There could
> be some ways to achieve this like allowing dot syntax for extensions from
> same module and arrow from any outer, so there are something like trusted
> and untrusted extensions, but this adds new concepts to language, which is
> also udesirable.
>
> Although, I am glad to see that this idea is still not discarded
> completely. I agree that the place where extensions are the most needed is
> fluent apis like streams, that could contain many operations in chain, and
> nesting makes code barely readable. As I understand, readability is what
> Java going for, so with some adjustments, such feature could enhance
> readability in some cases while not damaging it in another. The syntax
> Anatoly proposed could be a point where there are virtually aren't any
> major cons, while preserving all the pros.
>
>
> On Wed, Apr 24, 2024, 23:23 Anatoly Kupriyanov <kan.izh at gmail.com> wrote:
>
>> In my mind, the main motivation of extension methods is to rearrange the
>> syntax tree, replacing nesting calls with chaining, prefix with postfix.
>> I.e., replacing:
>> f1(f2(f3(x, "p3"), "p2", "p22"), "p1")
>> with
>> x.f3("p3").f2("p2", "p22").f1("p1")
>> It significantly untangles the code and makes it more readable. Good
>> example of good usage for it, could be the java-streams api, to add user
>> defined stream operations.
>>
>> as for "the illusion of belonging" it could be addressed by introducing
>> some special operator instead of dot to highlight the difference, e.g.
>> something like:
>> x¬f3("p3")¬f2("p2", "p22")¬f1("p1")
>>
>> On Wed, 24 Apr 2024 at 20:07, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>>>
>>> 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.
>>>
>>>
>>> You can convince yourself that you like it, but that doesn’t change the
>>> fact that it is a deliberate attempt to blur the boundary of the API.  And
>>> again, you might think that is fine, but we do not.  The members of String,
>>> and therefore the methods you can invoke through a String receiver, should
>>> be defined by the String class (and its supertypes.). Invoking a method on
>>> a receiver:
>>>
>>>     aString.encrypt()
>>>
>>> where String has no method called encrypt(), is muddying the user’s view
>>> of what the API of String is.  I get that you are willing to say “the API
>>> of String is the methods in String, plus any methods I care to create the
>>> illusion of belonging to String”, but that looks like monkey-patching to
>>> us.  Worse, this “method call” might mean one thing in one context, and
>>> another thing in another context.
>>>
>>> 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.
>>>
>>>
>>> Concision is not the goal of programming.
>>>
>>>
>>>
>>
>> --
>> WBR, Anatoly.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240424/3f5c1eb5/attachment.htm>