john.r.rose at oracle.com
Wed Jan 9 01:15:13 UTC 2019
I'm actually OK with the more concise and obscure notation, but I think
we need to note carefully where writability readability trades off against
readability, so we can tilt the language toward readability.
On Jan 8, 2019, at 4:07 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> While the aim is perhaps noble, make the code more explicit, your proposal have the same kind of issues we had before 8 when the compiler was asking to declare the captured local variables final.
> - your proposal transform the problem from "why does it compile ?" to "why it don't compile ?".
Yes, that is almost the definition of a "readability feature": It may be
harder to write, but is easier to understand once written.
> - if there is no declaration of 's', the error will be reported on 's' at the last line and most of the users will not know what to do.
A straw man, easily fixed by an error message that points at the
missed binding and says "did you mean…".
> - the IDEs may help, but you should be able to write a basic Java program without an IDE (in jshell by example) and IDEs may declare 's' at the wrong place (the wrong scope) anyway.
> - Groovy, Kotlin have already this kind of feature and the branding "hey look the compiler is smart" seems enough.
Yep; people are already learning to read such twisty code, so that
decreases the need for readability on this feature.
> - i'm not even sure it makes the code more readable, at lot of users will not understand the code because it's like you can use 's' in the then branch ( 's' is declared above after all ).
There's nothing new here: The 's' won't be usable on the then-branch
for the usual rules that pertain to definite assignment. I'm assuming
that Java students learn early that you can't use a variable that hasn't
been assigned yet.
More information about the amber-spec-observers