John’s proposal is really interesting, and I’ve had to mull it over for several days, and in the end the best I can say is that I lean slightly against it, not because it’s “wrong” but because I think that on balance it will require explaining more mechanism.
But now I will reveal my own bias: I feel that we are debating the best way to make code clear _after_ a programmer has already chosen to trade off clarity for some other convenience. I agree that we need to support all sorts of code transformation equivalences, even o n code that is structured in what I would regard as a suboptimal manner. I’m even happy to agree that there are differences of opinion about the relative desirability of minimizing code indentation and what concessions are acceptable for achieving that goal. Still, I believe that if you really care about making the structure of the code clear, then you would be well advised to (a) avoid inverting the sense of boolean tests, and (b) avoid relying on the fact that one arm of a conditional has a control transfer so that you can “get away with” saving a level of horizontal indentation. > On Jan 8, 2019, at 8:15 PM, John Rose <john.r.r...@oracle.com> wrote: > > 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 <fo...@univ-mlv.fr > <mailto:fo...@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. > > — John
