break seen as a C archaism

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "Louis Wasserman" <lowasser at google.com>, "Remi Forax" <forax at univ-mlv.fr>,
> "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 02:38:21
> Objet: Re: break seen as a C archaism

> There are three arguments why the N case is significantly different from the 2
> case.

> There are a number of idioms that require statements in addition to an
> expression. Debugging printfs, objects that take statements to initialize
> (construct/set/set/break), incrementing counters, cases that require side
> conditions (if today is tuesday do one thing, otherwise another), etc. Each
> individually is rare-ish, but not all that rare.

> The "static applicability" argument is that the larger the number of cases, the
> more likely one of them will fall into one these buckets, and then the whole
> thing has to fall back to statements. This makes expression switches less
> useful, and falling off this cliff is likely to irritate users every time it
> happens.

As Kevin said in the other thread, instead of refactoring the whole switch, you can also add a helper method, after all, if all cases but one are expressions, it seems to be a good hint that the code of that case should be extracted to a new method. 

They are few switchs in the code (apart if you do parsing, see all the John's examples or ASM codes), usually in a program you can count them, so for usual code, the more cases you use, the less it's likely to appear. 
And i conjecture that it exists a n such after n cases all switch that exists are all in the generated codes. 

> The “dynamic applicability” argument is that, if you want to change an existing
> switch (say, to add a debugging printf in one path), you have to refactor the
> whole thing. Which will be met, by users, with “YGBFKM.”

You mean if the case expression is enough complex that you want to print a part of it (otherwise you can printf the result of the switch), you have exactly the same issue with any complex expressions in Java, 
again, make the code simpler, create an helper method. 

> The “cliff height” argument says that falling off the cliff on a two-way
> conditional and having to refactor to if-else is far less painful than falling
> off the cliff on an N-way switch. Its a more painful refactor.

The "cliff height" argument was used by Josh Bosch when choosing if 'this' in a lambda should mean the lambda itself or the enclosing instance. 
So yes, sometimes, we will have to do a refactoring, IDEs will help, but the cliff height is only an argument if you have to jump over it often. 

> So for all these reasons, not being able to occasionally include some statements
> means many more switches that can’t use the feature (which is safer, clearer,
> and more compact), and also more often that the user will have to gratuitously
> refactor perfectly good code as they make small changes.

The 90% argument of Kevin is in my opinion stronger than these arguments. 

Rémi 

>> On Mar 13, 2018, at 8:59 PM, Kevin Bourrillion < [ mailto:kevinb at google.com |
>> kevinb at google.com ] > wrote:

>>>> - Do nothing; only allow single expressions. Non-starter.

>>> We're just saying the feature seems to be at least 90% as applicable without it.
>>> Roughly. Why is it a non-starter for the other 10% to stick with the switch
>>> they've always had? I'm sure there are good answers to that, I'm not doubting
>>> there are, but I think we should explore them instead of just declaring
>>> something a non-starter by fiat.

>> Also, if it is true that this is a "non-starter", I would assume it is also a
>> non-starter to only allow single expressions in the conditional operator `?:`.
>> If not, what is the fundamental difference?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/aaa7e46e/attachment-0001.html>