crazy idea: weaken the effectively final restriction

mark.yagnatinsky at barclays.com mark.yagnatinsky at barclays.com
Wed Oct 6 18:08:34 UTC 2021


Thank you.  I agree with most of that.  Except maybe the part that this is a greater burden on writers than readers.
Like you said, with IDE help, the burden on writers can be quite small.  (Except that you still need to choose a name.)
Agree that current way is more Java-like.  I guess my proposal is a bit more Perl-like: “please just do what I obviously mean”.
But yeah, it is hard to explain, even at the semi-formal level of detail most tutorials go for, let alone at the textbook or language spec level.

From: John Rose <john.r.rose at oracle.com>
Sent: Wednesday, October 6, 2021 1:57 PM
To: Yagnatinsky, Mark : Markets Pre Trade <mark.yagnatinsky at barclays.com>
Cc: jdk-dev at openjdk.java.net
Subject: Re: crazy idea: weaken the effectively final restriction


CAUTION: This email originated from outside our organisation - john.r.rose at oracle.com<mailto:john.r.rose at oracle.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
On Oct 5, 2021, at 2:55 PM, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:

Runnable f(String s) {
               s = normalize(s);
               return () -> println(s); // no can do: s is not effectively final
}

However, this seems a bit silly because although s is not final throughout the entire method, it's final where it actually matters.

As the experts have said, it is by design that the
finality can be applied to the declaration *regardless
of use*.  This yields a language that is easier to
reason about.  (Yes, we did spend a lot of complexity
budget elsewhere on lambdas as poly expressions,
which nobody understands.  To excuse that, that
bit of magic happens during overload resolution,
which nobody understood anyway.)


Namely, it is final from the point of capture to the end of the method, and that's the only condition we need to avoid those annoying questions.

I have wanted this feature from time to time, but
here’s another indication that it won’t pull its
weight (of complexity):  You can easily, even
automatically (with IDE help) work around the
limitation, simply by rebinding the variable
you intend to capture.  That’s the cost of
using the simpler (more reusable) semantics
of effectively final variables:  Sometimes
you need a second binding if the system
cannot read your mind about how you
are using the first binding.

Runnable f(String s) {
               s = normalize(s);
               var s1 = s;
               return () -> println(s1); // fixed it for you!
}


Something’s gotta give:  Either more mind-reading
rules for bindings, or more bindings.  This is arguably
the more Java-like approach.

Note also that the worst kind of mind-reading can
happen when a maintainer reads your code.  In that
case, the maintainer will surely prefer the more
transparent (though ceremonious) formulation
with s1.

Full disclosure:  As a coder I grumble every time
I have to write an “s1”.  But as a reader of code I
don’t mind them so much.

HTH



_________________________________________________________________________________________________________________________________________________________________________________________________________________________________
“This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer.

For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for the Investment Bank of Barclays where we trade with you in principal-to-principal wholesale markets transactions; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com.”  
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________
If you are incorporated or operating in Australia, please see https://www.home.barclays/disclosures/importantapacdisclosures.html for important disclosure.
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________
How we use personal information  see our privacy notice https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html 
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________


More information about the jdk-dev mailing list