<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 14, 2018 at 5:14 AM, Victor Nazarov <span dir="ltr"><<a href="mailto:asviraspossible@gmail.com" target="_blank">asviraspossible@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Wed, Mar 14, 2018 at 4:38 AM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are three arguments why the N case is significantly different from the 2 case.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.”<br>
<br>
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.<br></blockquote><div><br></div></span><div>As someone who participated in bringing this topic back to attention I'd like to say that I personally find these arguments substantial and persuasive. I think it's enough to bring me peace considering current switch-expression proposal (with restriction that we can't jump to a label outside switch block).</div></div></div></div></blockquote><div><br></div><div>Yes, this is a very substantive response to what makes expression switch different from `?:`. Thanks, Brian. I hope the point was still received that embedding statements inside an expression for immediate evaluation appears to be novel for Java. (All else being equal I assume that we are seeking to minimize novelty.)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The only argument against left is<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span class="">I think that there are features that make sense on their own, and there are<br></span>
features that *totally make lots of sense* assuming that you have heard the<span class=""><br>
expert group's passionate explanation of why they make sense. (It reminds<br>
me of a certain Pied Piper focus group near the end of Silicon Valley<br>
season 2, but moving on.) I am concerned that "breaking a value" is of the<br>
second kind."<br></span></div></blockquote><div><br></div><div>But this is not technical argument and I think it can't overweight technical ones.</div></div></div></div></blockquote><div><br></div><div>Oh, the quoted text doesn't constitute an "argument against" at all. It's attempting to be a reminder that "the existence of justifications that make sense to expert group type people" is not the same thing as "will fit nicely into the mental model of the 30th percentile Java developer". As this group debates language changes, I don't get a secure feeling that we are suitably concerned with what that mental model will be as opposed to what we think it <i>should</i> be. We don't get to actually <i>choose it; </i>users will pick it up from their own experiences interacting with the feature, and impressions they may soak up piecemeal from some page of a book, some slide of some presentation, (probably even more so) some muttered complaint of some colleague, etc. We can make only feeble attempts at best to nudge it directly.</div><div><br></div><div>I am certain I'm not saying anything that everyone here does not already know. However, is it clear that this group is thinking in these terms regularly? A <i>lot</i> of what needs to be discussed is discussed at a level where you need to be a compiler or VM engineer to even understand it. I don't have the chops to even participate in most of these discussions. I would like to figure out how we can satisfy ourselves that we are properly accounting for the perspective of the "ordinary" programmer.</div></div><br clear="all"><div>Now, back to the quoted response, about the relative value of "non-technical arguments", I am not completely sure what it means. One way to read it which I doubt was intended is that all this "usability stuff" doesn't matter as much as the technical challenges to rev the spec, compiler, and VM. I hope that wasn't it. :-)</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div></div>