My Experience with Primitive Patterns

[David Alayachew]

Hello Brian,

Anytime. This has been a long time coming for me, just been juggling a lot.
I'll take a better stab at Primitive Patterns once I get some breathing
room.

As for regularization, I definitely hit that pot hole too of not seeing the
real purpose, as you pointed out to me on Reddit.

And would love to see that identification logic for pattern conflicts.
Thanks for considering.

On Tue, Nov 26, 2024 at 9:21 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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/b97c0233/attachment.htm>