[External] : Re: Semantics of multiple patterns with the same prefix in a switch

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Lundi 1 Février 2021 20:42:40
> Objet: Re: [External] : Re: Semantics of multiple patterns with the same prefix in a switch

[...]

> And let’s also keep in mind that if we have the “dumb and predictable thing” as
> a baseline, then, after all, the programmer also has some control over the
> situation: if performance of
> 
>    case Foo(A a):
>    case Foo(B b):
>    case Bar(C c):
>    case Bar(D d):
>    case Wooga(E e):
> 
> is not satisfactory because it’s a Foo 99% of the time (that’s why the Foo cases
> were listed firs, after all?!),

If one class dominate the other at runtime, i hope the metafactory (or the VM or both) will re-organize the code so having 99% of Foo or 99% of Bar the code should perform as fast,
as Brian said, you can either have Foo, Bar or Wooga, so you can permute them (method calls already works that way).

> then the switch can easily be refactored (with IDE assistance?) to either
> 
>    case Foo z:
>	switch (z) {
>            case Foo(A a):
>            case Foo(B b):
>        }
>    case Bar z:
>	switch (z) {
>            case Bar(C c):
>            case Bar(D d):
>        }
>    case Wooga z:
>	switch (z) {
>            case Wooga(E e):
>        }
> 
> (which works in the general case where patterns may have more than one argument)
> or
> 
>    case Foo(var z):
>	switch (z) {
>            case A a:
>            case B b:
>        }
>    case Bar(var z):
>	switch (z) {
>            case C c:
>            case D d:
>        }
>    case Wooga(var z):
>	switch (z) {
>            case E e:
>        }

No, this refactoring is not allowed by the baseline semantics because you are collapsing two calls to the deconstructor (of Foo or the other) into one.
This refactoring is only valid with the "clever head" strategy and it's a nice example of why the baseline semantics may not be enough.

[...]

> 
> Thus the programmer can always micromanage the dispatch structure if performance
> is an issue.  And the performance model for the baseline approach is pretty
> straightforward and should be easy to understand.

There is already so many things we already have in our head when we write codes, if i can avoid micromanaging the switch, i see that as a plus.

regards,
Rémi