My Experience with Primitive Patterns

[Brian Goetz]

Thanks David.  People don't always post their "I tried out the new thing 
and it worked as advertised" experiences.

One thing that is often misunderstood about this JEP is that it is more 
about _regularization_ than adding a whizzy cool new feature (which 
often causes people to respond with "but I don't see when I would use 
it" comments.)  The point of "regularization" activities like this is 
that sharp edges that we've just gotten used to, can be handled within 
the normal framework.  When it works right, you shouldn't notice it at all.

(Regarding switching over booleans: a useful thought experiment would 
be, if we had exhaustive switch expressions over booleans in 1995, would 
we even have wanted to add a ternary?  (It's a thought experiment, 
doesn't need to become a discussion here.))

> error: duplicate unconditional pattern
>
> This error threw me for a loop when I first saw it. 

error: neither throwing nor looping in your example

Seriously, it is reasonable for the error message to try to identify 
which patterns are unconditional.  We do this with overload selection 
conflicts, with type inference conflicts, and it seems reasonable to do 
so with pattern conflicts as well.


On 11/25/2024 11:58 PM, David Alayachew wrote:
> Hello Amber Dev,
>
> I just wanted to post my experience with using Primitive Patterns when 
> trying it out in a non-trivial project.
>
> First off, one of the things that stood out to me immediately is how 
> little effort it became to isolate and properly handle edge cases. 
> Previously, if I wanted to provide a validation for all the different 
> ways that this int could be wrong, I would need a separate if 
> statement or a library. Typically, I would just group all of my checks 
> into a single if check or boolean, leading to error prone-code. But 
> now, just a simple when clause on a switch. Then, just throw on the 
> right hand side for the bad cases, and return itself on the good 
> cases. My validation code was easier to work with.
>
> Another thing that I DEEPLY appreciated was the exhaustiveness 
> checking for boolean. That made a lot of my code a lot more explicit, 
> which I appreciated. Granted, it ended up being more verbose, but I 
> don't mind verbosity.
>
> One minor annoyance, this one error message was a bit difficult to 
> follow without looking things up.
>
> error: duplicate unconditional pattern
>
> This error threw me for a loop when I first saw it. I NOW know it is 
> exactly what it means (after having done the necessary research from 
> the amber docs), but the error message could do with a bit more 
> context. Maybe clarify which case is the duplicate? If that's a hard 
> thing to do, then no worries. I only raise this issue in case the 
> assumption is that the average Java programmer will look at that error 
> and have a good idea of what it means without doing a non-trivial 
> amount of reading.
>
> Honestly, there's not much else to write. It all just worked. I will 
> give Primitive Patterns another test in the future, once I have time.
>
> Thank you all for your time and attention.
> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241126/e676cbbd/attachment.htm>