break seen as a C archaism

[Kevin Bourrillion]

On Wed, Mar 14, 2018 at 5:14 AM, Victor Nazarov <asviraspossible at gmail.com>
wrote:

On Wed, Mar 14, 2018 at 4:38 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> 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.
>>
>> 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.”
>>
>> 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.
>>
>
> 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).
>

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.)


The only argument against left is
>
> I think that there are features that make sense on their own, and there are
>> features that *totally make lots of sense* assuming that you have heard
>> the
>> expert group's passionate explanation of why they make sense. (It reminds
>> me of a certain Pied Piper focus group near the end of Silicon Valley
>> season 2, but moving on.) I am concerned that "breaking a value" is of the
>> second kind."
>>
>
> But this is not technical argument and I think it can't overweight
> technical ones.
>

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 *should* be. We don't get to actually *choose it; *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.

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 *lot* 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.

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. :-)

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180314/6b445b29/attachment.html>