The case for no case

[Brian Goetz]

So, its always good to walk back from the "solution" and try to distill 
the problem you are trying to solve.

One thing I think you are saying is: Let's be careful that we don't just 
blindly extrapolate from "A switch is a bunch of things, all of which 
start with 'case'".  This is of course true now, but we should be aware 
that there is more than one way to consistently extrapolate from the 
present.

Another thing that I think you're saying is: Currently all our patterns 
are constants, and they are denoted like constant literals, but beware, 
when you start to mix literal-looking thingies to more complex patterns, 
it may get ambiguous.  (Or is that what I'm saying?)



On 6/6/2020 10:19 AM, forax at univ-mlv.fr wrote:
> Let's try again with a different camera angle.
>
> If i want to write the equals of a record Point, using instanceof, I 
> can write
> record Point(int x, int y) {
>   public boolean equals(Object o) {
>     return o instanceof Point(x, y);
>   }
> }

Alarm, alarm!  No one has proposed that you should be allowed to use a 
(mutable!) variable as a nested pattern in this way!  But if you want to 
ask this question, you could write:

     o instanceof Point(var xx, var yy) && xx == x && yy == y;

Now, maybe you want to say "yuck, I don't want to write that." Maybe 
you'd be happy if you could say:

     o instanceof Point(== x, == y)

where `== expr` is a pattern that matches its target if, well, the 
target is equal to the expression?

> I don't have the solution, maybe this problem is just because we are 
> introducing new patterns but in 10 years, people will be used too.

Sure, let's step back: what's the problem you are worried about?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200606/22aab800/attachment.htm>