Expression switch - an alternate proposal
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Apr 13 07:35:09 UTC 2018
I think it's better to first introduce the expression switch with the break syntax and then go to the shorthand syntax than do the opposite.
So first,
var topping = switch (food) {
case BURGER: break KETCHUP;
case SAUSAGE, ASPARAGUS: break MUSTARD;
case ICE_CREAM: break FUDGE;
default: break NOTHING;
};
then, introducing a case with several statements
var topping = switch (food) {
case BURGER: break KETCHUP;
case SAUSAGE, ASPARAGUS: break MUSTARD;
case ICE_CREAM: break FUDGE;
case BAKED_POTATO:
Toppings t = new Toppings();
t.add(BACON);
t.add(SOUR_CREAM);
t.add(CHEESE);
t.add(BACON); // not a typo
break t;
default: break NOTHING;
};
and then introduce the shorthand syntax for a single expression
var topping = switch (food) {
case BURGER: KETCHUP;
case SAUSAGE, ASPARAGUS: MUSTARD;
case ICE_CREAM: FUDGE;
case BAKED_POTATO:
Toppings t = new Toppings();
t.add(BACON);
t.add(SOUR_CREAM);
t.add(CHEESE);
t.add(BACON); // not a typo
break t;
default: NOTHING;
};
(in my current mental world the shorthand syntax use ':' and not '->')
Rémi
----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "cay horstmann" <cay.horstmann at gmail.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Jeudi 12 Avril 2018 14:48:06
> Objet: Re: Expression switch - an alternate proposal
> I think Remi has it exactly right here: this is a pedagogical blessing
> in disguise -- as long as we can let go our of pre-existing notions of
> how it ought to be taught.
>
> The switch statement is nasty and complicated in multiple ways; surely
> you don't want to teach that first if you have a choice. So start with
> the simplified form of the switch expression:
>
> topping = switch (food) {
> case BURGER -> KETCHUP;
> case SAUSAGE, ASPARAGUS -> MUSTARD;
> case ICE_CREAM -> FUDGE;
> default -> NOTHING;
> }
>
> Students should be able to grasp this immediately; if its one of the
> things on the left, pick the thing on the right. You can get a long way
> with this.
>
> Eventually you will come across a situation where the right-hand side is
> not a simple expression. Then you can teach them the escape hatch for
> adding statements into the mix:
>
> topping = switch (food) {
> case BURGER -> KETCHUP;
> case SAUSAGE, ASPARAGUS -> MUSTARD;
> case ICE_CREAM -> FUDGE;
> case BAKED_POTATO:
> Toppings t = new Toppings();
> t.add(BACON);
> t.add(SOUR_CREAM);
> t.add(CHEESE);
> t.add(BACON); // not a typo
> break t;
> default -> NOTHING;
> }
>
> You can explain that "break" in a switch is like "return" in a method.
> While the "spelling" might seem weird, the concept is not hard.
>
> Now, when you need to, you can teach the switch statement in all its
> glory. They've already seen switching; they've already seen breaking;
> what's left it to explain fallthrough (no way around this) and the lack
> of exhaustiveness.
>
>
> Which is to say:
>
> - New users can probably learn the concepts better by adding them in
> one at a time; first simple expression switches, then adding in break,
> then statement switches.
>
> - Existing users, who have already been through the gauntlet of
> learning fallthrough, will necessarily learn it in the opposite order,
> but they should be able to recognize that break means the same thing it
> always has, so there are still relatively few new concepts here.
>
> This seems like a pretty good pedagogical story either way!
>
>
>
> On 4/12/2018 3:23 AM, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "Cay Horstmann" <cay.horstmann at sjsu.edu>
>>> À: "amber-dev" <amber-dev at openjdk.java.net>
>>> Envoyé: Jeudi 12 Avril 2018 06:50:35
>>> Objet: Re: Expression switch - an alternate proposal
>>> I've thought about this more and in the end decided to speak up. Over
>>> the years, I explained a substantial number of Java features to a very
>>> large number of people, and I generally have a pretty good idea of where
>>> people struggle. Anonymous inner classes, wildcards, constructor
>>> references, the unnamed module, you name it. With all of these features,
>>> I knew I had my work cut out explaining them, but I wasn't too bothered.
>>>
>>> I am bothered by the proposed expression switch syntax.
>>>
>>> When I read these discussions about colons vs. arrows, I fear that they
>>> mask a much bigger issue. I do not think that there is significant
>>> transfer from the existing switch statement to what we want to achieve
>>> with expression switch. The matching part is similar, but the control
>>> flow is not.
>> the control flow of an expression switch is a subset of the control flow of a
>> statement switch because it's an expression.
>>
>>> Maybe I am wrong. If there has been user testing that confirms that
>>> programmers properly transfer their knowledge of statement switch to
>>> expression switch with the "break x" syntax, that's great, and I'll shut
>>> up. In absence of such evidence, I would urge (1) to make expression
>>> switch visibly different from statement switch and (2) have an ironclad
>>> justification for "break x" or abandon it. It has tension with labeled
>>> break and classic break which can be present inside a branch of an
>>> expression switch. Teaching a break/return analogy does not seem any
>>> easier than teaching about block expressions.
>> You can not have a break label (or a continue) inside a switch expression, again
>> it's an expression, it's like ?:, you can have a break label into it.
>>
>> I disagree that teaching block expressions is as easy that teaching break
>> expression, with block expressions, you also have to teach why you can not use
>> it anywhere else in Java.
>> The break expression does not have this issue. BTW, i think it's easy in term of
>> teaching to teach the switch expression first and then to teach the statement
>> switch given that the expression switch semantics is a subset of the statement
>> switch semantics.
>>
>>> Cheers,
>>>
>>> Cay
>>>
>>>
>> Rémi
>>
>>>
>>> Le 10/04/2018 à 13:59, Stephen Colebourne a écrit :
>>>> On 10 April 2018 at 09:02, <forax at univ-mlv.fr> wrote:
>>>>>>> Basically, your proposal is to use -> eveywhere, i think i prefer the opposite,
>>>>>>> do not use arrow at all.
>>>> Current Oracle proposal:
>>>> statements = colon
>>>> expression = colon, with arrow for expressions
>>>>
>>>> Alternate proposal:
>>>> statements = colon
>>>> expression = symbol-that-isnt-colon
>>>>
>>>> Remi proposal:
>>>> statements = colon
>>>> expression = colon
>>>>
>>>> If the goal is a unified switch expression, Remi proposal wins. It is
>>>> dead simple and very consistent.
>>>>
>>>>>> This is a reasonable alternative, but I don't think it would be very
>>>>>> popular. I think people will really love being able to write:
>>>>>>
>>>>>> case MONDAY -> 1;
>>>>>> case TUESDAY -> 2;
>>>>>>
>>>>>> and will be sad if we make them write
>>>>>>
>>>>>> case MONDAY: break 1;
>>>>>> case TUESDAY: break 2;
>>>> Meh. Three more characters.
>>>>
>>>> Yet:
>>>> - Avoids the arrow having a conflict of meaning with lambda.
>>>> - No mixed arrows & colons
>>>> - Much more consistent.
>>>> - Minimal change from existing switch.
>>>> - Less to learn.
>>>> Win, win, win.
>>>>
>>>> So while I'd still choose to have a separate symbol for expression and
>>>> statement switches (because of my #1 goal), I'm also pretty fine with
>>>> the Remi proposal (because my #2 goal).
>>>>
>>>> In fact, what the discussion has informed me is that my #1 and #2
>>>> goals are the wrong way around. Getting rid of the mixed arrows and
>>>> colons is now more important to me than understanding the context in a
>>>> large switch.
>>>>
>>>> Stephen
>>>>
>>>
>>> --
>>>
> >> Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com
More information about the amber-dev
mailing list